Re: [yocto] [meta-chip] Yocto on the 9$ computer
Andrei good work. > On Oct 24, 2015, at 1:13 PM, Andrei Gherzan wrote: > > On Sat, Oct 24, 2015 at 09:58:42PM +0200, Nicolas Aguirre wrote: >> 2015-10-24 19:26 GMT+02:00 Andrei Gherzan : >>> Hi all, >>> >> >> Hi Andrei, >> >>> Have a C.H.I.P. 9$ computer? It works with Yocto now. >>> >>> http://layers.openembedded.org/layerindex/branch/master/layer/meta-chip/ >>> >> Good job. >> IMO it make sense to add C.H.I.P support in meta-sunxi, don't you think ? >> >> https://github.com/linux-sunxi/meta-sunxi >> > > Well. Temporary it is a separate layer. And this is mainly because of the > overhead you need for flashing the board. So I do see a benefit in keeping it > separately. We will see in time. what does board flashing has to do with layer infrastructure ? when creating a new layer all we should think that it should make it easy for end user to use the ecosystem and reduce confusion. That also might mean that you may have different layers for chips coming from same SOC vendor but it is contextual, e.g. if you are using same u-boot and kernel trees as rest of sunxi then you better align it in sunxi layer e.g. > > Thanks for feedback. > > -- > Andrei Gherzan > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "bitbake meta-toolchain", QA Issue, library in wrong location
> On Oct 30, 2015, at 4:36 AM, Robert P. J. Day wrote: > > > goofing around, did a "bitbake meta-toolchain" for my BBB > configuration and, toward the end, got: > > WARNING: QA Issue: gcc-cross-canadian-arm-dbg: found library in wrong > location: > /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/.debug/libcc1.so.0.0.0 > gcc-cross-canadian-arm-dbg: found library in wrong location: > /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/.debug/libcc1plugin.so.0.0.0 > gcc-cross-canadian-arm-dbg: found library in wrong location: > /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/.debug/liblto_plugin.so.0.0.0 > gcc-cross-canadian-arm: found library in wrong location: > /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/libcc1.so.0.0.0 > gcc-cross-canadian-arm: found library in wrong location: > /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/libcc1.so > gcc-cross-canadian-arm: found library in wrong location: > /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/liblto_plugin.so.0 > gcc-cross-canadian-arm: found library in wrong location: > /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/libcc1plugin.so.0.0.0 > gcc-cross-canadian-arm: found library in wrong location: > /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/libcc1plugin.so.0 > gcc-cross-canadian-arm: found library in wrong location: > /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/liblto_plugin.so.0.0.0 > gcc-cross-canadian-arm: found library in wrong location: > /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/libcc1.so.0 > gcc-cross-canadian-arm: found library in wrong location: > /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/liblto_plugin.so > gcc-cross-canadian-arm: found library in wrong location: > /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/libcc1plugin.so > [libdir] > WARNING: QA Issue: nativesdk-qemu rdepends on nativesdk-libbz2, but it > isn't a build dependency? [build-deps] > > is the above anything i need be concerned about? it's still baking > so i haven't had a chance to test it yet. I think it should be ok. For cross canadian may be this check should be disabled. > > rday > > -- > > > Robert P. J. Day Ottawa, Ontario, CANADA >http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH][yocto-docs] typo, "buiding images"
Signed-off-by: Robert P. J. Day --- not sure if this is sufficient, there seems to be no other related typo. diff --git a/documentation/adt-manual/adt-prepare.xml b/documentation/adt-manual/adt-prepare.xml index 65df1d0..893211b 100644 --- a/documentation/adt-manual/adt-prepare.xml +++ b/documentation/adt-manual/adt-prepare.xml @@ -481,7 +481,7 @@ To get the kernel and filesystem images, you either have to build them or download pre-built versions. For an example of how to build these images, see the -"Buiding Images" +"Building Images" section of the Yocto Project Quick Start. For an example of downloading pre-build versions, see the "Example Using Pre-Built Binaries and QEMU" -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH] samhain: upgrade to 4.1.0
Li Xin,
Master-next already has the 4.1.0 update. I have merged the additional
fixes to master-next.
thanks,
Armin
On 10/30/2015 02:37 AM, Li xin wrote:
> From: Li Xin
>
> Also fix an error when "samhain -t check" is executed.
> The error is like this:
> 'ERROR: msg=,
> subroutine=, path=<(null)>'
>
> Signed-off-by: Li Xin
> ---
> .../samhain/{samhain-client_4.0.0.bb => samhain-client_4.1.0.bb}| 3 ++-
> .../samhain/{samhain-server_4.0.0.bb => samhain-server_4.1.0.bb}| 0
> recipes-security/samhain/samhain.inc| 6
> +++---
> 3 files changed, 5 insertions(+), 4 deletions(-)
> rename recipes-security/samhain/{samhain-client_4.0.0.bb =>
> samhain-client_4.1.0.bb} (79%)
> rename recipes-security/samhain/{samhain-server_4.0.0.bb =>
> samhain-server_4.1.0.bb} (100%)
>
> diff --git a/recipes-security/samhain/samhain-client_4.0.0.bb
> b/recipes-security/samhain/samhain-client_4.1.0.bb
> similarity index 79%
> rename from recipes-security/samhain/samhain-client_4.0.0.bb
> rename to recipes-security/samhain/samhain-client_4.1.0.bb
> index c671b48..bb47449 100644
> --- a/recipes-security/samhain/samhain-client_4.0.0.bb
> +++ b/recipes-security/samhain/samhain-client_4.1.0.bb
> @@ -8,7 +8,8 @@ EXTRA_OECONF += " \
> --with-logserver=${SAMHAIN_SERVER} \
> --with-port=${SAMHAIN_PORT} \
> --with-config-file=/etc/samhainrc \
> ---with-data-file=/var/lib/samhain/samhain_file \
> +--with-data-file=/var/samhain/samhain.data \
> +--with-pid-file=/var/samhain/samhain.pid \
> "
>
>
> diff --git a/recipes-security/samhain/samhain-server_4.0.0.bb
> b/recipes-security/samhain/samhain-server_4.1.0.bb
> similarity index 100%
> rename from recipes-security/samhain/samhain-server_4.0.0.bb
> rename to recipes-security/samhain/samhain-server_4.1.0.bb
> diff --git a/recipes-security/samhain/samhain.inc
> b/recipes-security/samhain/samhain.inc
> index e33182f..dedcf76 100644
> --- a/recipes-security/samhain/samhain.inc
> +++ b/recipes-security/samhain/samhain.inc
> @@ -8,9 +8,8 @@ SRC_URI =
> "http://la-samhna.de/archive/samhain_signed-${PV}.tar.gz \
> file://${INITSCRIPT_NAME}.init \
> file://${INITSCRIPT_NAME}.default \
> "
> -
> -SRC_URI[md5sum] = "2144383cc5452b9b80c7e4e4c991ad4a"
> -SRC_URI[sha256sum] =
> "5a841708f78c6d9b4731970fa39151dff366885de08ecddc382e8c45a2c1b4e2"
> +SRC_URI[md5sum] = "fcb59c6c8a1d30cc6ffc21557a0046d3"
> +SRC_URI[sha256sum] =
> "a8e10454782a7f3bb5f709dd05cee695ffbd052afc709668a3e7c4b629771189"
>
> S = "${WORKDIR}/samhain-${PV}"
>
> @@ -87,4 +86,5 @@ do_install_append () {
> install -d ${D}${docdir}/${PN}
> cp -r docs/* ${D}${docdir}/${PN}
> cp -r scripts ${D}${docdir}/${PN}
> +install -d -m 755 ${D}/var/samhain
> }
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Toolchains of different architectures overwrite files
On 10/30/15 12:07 PM, Lorenz B. wrote:
> Hello,
>
> I setup yocto (fido fa55b8e") with
> source oe-init-build-env build-qemu
> and changed MACHINE to "none" and PACKAGE_CLASSES to "package_ipk" in
> conf/local.conf
>
>
> built an arm and a mips toolchain with the following commands:
> export MACHINE=qemuarm; bitbake meta-toolchain
> export MACHINE=qemumips; bitbake meta-toolchain
>
> Installed and reanmed the toolchains like this:
> ./poky-glibc-x86_64-meta-toolchain-armv5e-toolchain-1.8.1.sh -d poky
> mv poky poky-arm
> ./poky-glibc-x86_64-meta-toolchain-mips32r2-toolchain-1.8.1.sh -d poky
> mv poky poky-mips
>
>
> And created md5 sums from both x86_64-pokysdk-linux sysroots:
> cd poky-arm/sysroots/x86_64-pokysdk-linux
> find . -type f -exec md5sum {} \; > ../../../arm.md5
> cd -
>
> cd poky-mips/sysroots/x86_64-pokysdk-linux/
> find . -type f -exec md5sum {} \; > ../../../mips.md5
> cd -
You can't just md5sum. Different builds will generate different md5 sums due to
embedded data states, build stamps, build id, etc.
You need to actually use a program to compare the binaries themselves
(specifically the sections).
Anything that is taged with an arch type is specific to the target of your
compilation. Anything else, the comparisons of the sections should be the same
within the limitations of those embedded components. If there is a deviation,
then we should be able to look into it.. but the md5sum just says they were
built at different times to me -- and doesn't tell me there is a problem.
--Mark
> and finaly compared the two md5 files with
> colordiff -u arm.md5 mips.md5 | less -R
> to be sure that everything is equal. But to my surprise, it isn't equal.
>
> There are some files which don't exist in the other toolchain in
> architecture specific directories which might be ok.
> But there are some files which would be overwritten if both toolchains
> are installed to the same location like the default /opt/poky/1.8.1.
> And for every toolchain I install the last one wins.
>
> Do I use those toolchains in a wrong fashion if I install them all in
> the default path?
> And if not, why doesn't it bother that files are overwritten?
>
> Best regards,
> Lorenz
>
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] prelink: AARCH64 support added
I've applied you patch to a new 'cross_prelink_aarch64' branch for testing. A few notes: I cleaned up some white space issues. This might have been a result of the mailer -- I'm not sure. I had to change: R_AARCH64_TLS_DTPMOD64 to R_AARCH64_TLS_DTPMOD R_AARCH64_TLS_DTPREL64 to R_AARCH64_TLS_DTREL R_AARCH64_TLS_TPREL64 to R_AARCH64_TLS_TPREL >From what I can find, the names of these symbols were modified in: https://sourceware.org/ml/libc-alpha/2014-11/msg00455.html I found another note that the aarch64 ABI has gone through a few revisions where the notation has come back -- but glibc has not yet re-introduced it to it's 'elf.h' file. Now for the testing part. Running the testsuite (make check), I'm getting a number of failures. I'm running the tests on a YP 2.0 based system, with two patches applied to glibc. The one that should fix the prelink load address issue, and the other that should fix the ld.so interface. The results of the 'make check' are: Testsuite summary for # TOTAL: 47 # PASS: 4 # SKIP: 6 # XFAIL: 0 # FAIL: 37 # XPASS: 0 # ERROR: 0 Of the fails, the 'tls*' tests cause kernel back traces on my system. (Definitely not good.) 'ifunc' tests were skipped as as aarch64 does not have a definition in ifunc.h The other failures can be classified as: - unprelink failed (input and output were not identical) - execution of the prelinked code failed I'd suggest start working through the issues in the testsuite... --Mark On 10/30/15 8:34 AM, Mark Hatle wrote: > Was the work below based on any existing work (such as arch-arm.c)? We found > a > bug yesterday in the "arm_prelink_conflict_rela" on ARM, a previous hunk for > handling ifuncs was missed. > > See: > http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/commit/?h=cross_prelink_staging&id=927979bbd115eeb8a75db3231906ef6aca4c4eb6 > > Also we really need to add a test case for ifunc processing to the testsuite. > Look at testsuite/ifunc.h. > > Otherwise, we're likely to experience some breakage in ifunc processing in the > future. > > Thank you for the contribution. I'll be looking at it soon and try running > it. > > --Mark > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Status WW44
Current Dev Position: YP 2.0 Final (preparing rc3) Next Deadline: YP 2.0 Final Release Target: Oct. 30, 2015 (We are targeting Nov. 6th) SWAT team rotation: Juro -> Anibal https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Top Bugs to be tackled (2.0 release blockers): * systemd timeouts in the sanity tests (#8141, #8142) * 8124 - SDK on i686 install issue. * YP 2.0 rc2 QA test report: https://wiki.yoctoproject.org/wiki/WW43_-_2015-10-22_-_Full_Pass_2.0.rc2 * Basically, we have a number of bugs with Medium+ priority listed in the above test report which will prevent us from releasing rc2. Key Status/Updates: * We have approved YP 1.8.1 rc1 for release, it should go out early next week. * YP 1.7.3 rc1 is in QA. * We will be doing an YP 2.0 rc3, which will push the release past Oct. 30th targeted release date. Current earliest estimate for release is Nov. 6th, but it could slip to a later date if the critical top bugs are not resolved. Reminders: * We have renamed YP 1.9 to YP 2.0. * The current version that is in development is planned to launch as YP 2.0 in early Nov., 2015. * The release name for YP 2.0 is 'jethro'. Key YP 1.9/2.0 Dates: YP 2.0 Final - 2.0 Cut off: Sept. 28, 2015 noon GMT (rc2 is in QA) YP 2.0 final Release Target: Oct. 30, 2015 (We are targeting Nov. 6th) Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.9_Status https://wiki.yoctoproject.org/wiki/Yocto_1.9_Schedule https://wiki.yoctoproject.org/wiki/Yocto_1.9_Features Tracking Metrics: WDD 2032 (last week 2113) (https://wiki.yoctoproject.org/charts/combo.html) [If anyone has suggestions for other information you'd like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone: (503) 712-0534 *Cell:(208) 244-4460 * Email: stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] kernel defconfig configuration
On Fri, Oct 30, 2015 at 8:10 AM, Daniel. wrote: > I saw that REMOTEPROC is selected by other *_REMOTEPROC config > options. It seems a driver to handle another process on same board, > right? > It seems also that other architetures select REMOTEPROC, so if you're > creating a new board with a remote processor I guess that you will > need to > create a remote processor driver and add CONFIG_YOURARCH_REMOTEPROC to > drivers/remoteproc/Kconfig, and make that selects REMOTEPROC as > OMAP_REMOTEPROC does > for example. OK, that makes sense. Thanks everyone! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] kernel defconfig configuration
I saw that REMOTEPROC is selected by other *_REMOTEPROC config options. It seems a driver to handle another process on same board, right? It seems also that other architetures select REMOTEPROC, so if you're creating a new board with a remote processor I guess that you will need to create a remote processor driver and add CONFIG_YOURARCH_REMOTEPROC to drivers/remoteproc/Kconfig, and make that selects REMOTEPROC as OMAP_REMOTEPROC does for example. Best regards, 2015-10-30 10:39 GMT-02:00 Bruce Ashfield : > On 15-10-29 03:06 PM, Edward Wingate wrote: >> >> On Thu, Oct 29, 2015 at 6:10 AM, Bruce Ashfield >> wrote: >>> >>> That's the kernel's configuration subsystem at play, it still has to >>> process the the defconfig (which was placed as .config before starting >>> the kernel build). Invalid options are removed, others are selected >>> by Kconfigs, etc. So what you end up with is the processed .config and >>> your old one in .config.old. >> >> >> Ah, OK, it's possible the option I wanted (CONFIG_REMOTEPROC) is not >> available for my machine (imx6/wandboard) and so removed. Where can I >> look to see if a config option is valid for a particular >> machine/architecture? > > > I'm working on some patches that will show you that as part of the > configuration audit task (there's potentially a library I can > leverage) .. but for now, either looking at the Kconfig's or running > menuconfig are the best (brute force) way to find what is missing. > > Bruce > >> >> Thanks for the help. >> > -- "Do or do not. There is no try" Yoda Master -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] prelink: AARCH64 support added
Was the work below based on any existing work (such as arch-arm.c)? We found a
bug yesterday in the "arm_prelink_conflict_rela" on ARM, a previous hunk for
handling ifuncs was missed.
See:
http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/commit/?h=cross_prelink_staging&id=927979bbd115eeb8a75db3231906ef6aca4c4eb6
Also we really need to add a test case for ifunc processing to the testsuite.
Look at testsuite/ifunc.h.
Otherwise, we're likely to experience some breakage in ifunc processing in the
future.
Thank you for the contribution. I'll be looking at it soon and try running it.
--Mark
On 10/30/15 1:50 AM, Maninder Singh wrote:
> This patch adds support for prelinking in AARCH64.
> To run prelink on successfully on target following changes are done
> 1. aarch64/dl-machine.h: Fix load-address for prelink support
>https://sourceware.org/ml/libc-alpha/2015-10/msg00575.html
> 2. To handle relocation R_AARCH64_TLSDESC, Conflicts are raised for
>R_AARCH64_TLSDESC.
>Conflicts of relocation type R_AARCH64_TLSDESC is handled by
>_dl_tlsdesc_undefweak which return the addend minus the thread pointer.
>Hacked _dl_tlsdesc_undefweak to return addend only. Need to Fix this hack.
>
> Signed-off-by: Vaneet Narang
> Signed-off-by: Maninder Singh
> ---
> trunk/src/Makefile.am|2 +-
> trunk/src/arch-aarch64.c | 594
> ++
> trunk/src/dso.c |1 +
> 3 files changed, 596 insertions(+), 1 deletions(-)
> create mode 100644 trunk/src/arch-aarch64.c
>
> diff --git a/trunk/src/Makefile.am b/trunk/src/Makefile.am
> index 7372fc1..d6cc5cb 100644
> --- a/trunk/src/Makefile.am
> +++ b/trunk/src/Makefile.am
> @@ -24,7 +24,7 @@ bin_PROGRAMS = execstack
>
> arch_SOURCES = arch-i386.c arch-alpha.c arch-ppc.c arch-ppc64.c \
> arch-sparc.c arch-sparc64.c arch-x86_64.c arch-mips.c \
> -arch-s390.c arch-s390x.c arch-arm.c arch-sh.c arch-ia64.c
> +arch-s390.c arch-s390x.c arch-arm.c arch-sh.c arch-ia64.c
> arch-aarch64.c
> common_SOURCES = checksum.c data.c dso.c dwarf2.c dwarf2.h fptr.c fptr.h
> \
>hashtab.c hashtab.h mdebug.c prelink.h stabs.c crc32.c \
>wrap-file.c canonicalize.c reloc-info.c reloc-info.h
> diff --git a/trunk/src/arch-aarch64.c b/trunk/src/arch-aarch64.c
> new file mode 100644
> index 000..13713b2
> --- /dev/null
> +++ b/trunk/src/arch-aarch64.c
> @@ -0,0 +1,594 @@
> +/* Copyright (C) 2001, 2002, 2003, 2004, 2006, 2009 Red Hat, Inc.
> + Written by Jakub Jelinek , 2001.
> + Copyright (C) 2015 Samsung Electronics Co., Ltd. All rights reserved.
> + ARM64 support by Vaneet Narang
> +
> + This program is free software; you can redistribute it and/or modify
> + it under the terms of the GNU General Public License as published by
> + the Free Software Foundation; either version 2, or (at your option)
> + any later version.
> +
> + This program is distributed in the hope that it will be useful,
> + but WITHOUT ANY WARRANTY; without even the implied warranty of
> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + GNU General Public License for more details.
> +
> + You should have received a copy of the GNU General Public License
> + along with this program; if not, write to the Free Software Foundation,
> + Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "prelink.h"
> +
> +/* The aarch64 ABI:
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf
> + * documents a "class" value for specific reads and writes. All this
> + * indicates is that we should be using the ELFCLASS to determine if
> + * this should be a 32/64 bit read/write. (See table 4.9)
> + *
> + * We emulate this behavior below...
> + */
> +#define read_uneclass(DSO, ADDR) \
> +( gelf_getclass(DSO->elf) == ELFCLASS32 ? read_une32(DSO, ADDR) :
> read_une64(DSO, ADDR) )
> +
> +#define write_neclass(DSO, ADDR, VAL) \
> +( gelf_getclass(DSO->elf) == ELFCLASS32 ? write_ne32(DSO, ADDR, VAL) :
> write_ne64(DSO, ADDR, VAL) )
> +
> +#define buf_write_neclass(DSO, BUF, VAL) \
> +( gelf_getclass(DSO->elf) == ELFCLASS32 ? buf_write_ne32(DSO, BUF, VAL) :
> buf_write_ne64(DSO, BUF, VAL) )
> +
> +static int
> +aarch64_adjust_dyn (DSO *dso, int n, GElf_Dyn *dyn, GElf_Addr start,
> +GElf_Addr adjust)
> +{
> +int testec = addr_to_sec (dso, dyn->d_un.d_ptr);
> + if (dyn->d_tag == DT_PLTGOT)
> +{
> + int sec = addr_to_sec (dso, dyn->d_un.d_ptr);
> + Elf64_Addr data;
> +
> + if (sec == -1)
> + return 0;
> +
> + data = read_une64 (dso, dyn->d_un.d_ptr);
> + /* If .got.plt[0] points to _DYNAMIC, it needs to be adjusted. */
> + if (data == dso->shdr[n].sh_addr && data >= start)
> + write_ne64 (ds
Re: [yocto] kernel defconfig configuration
On 15-10-29 03:06 PM, Edward Wingate wrote: On Thu, Oct 29, 2015 at 6:10 AM, Bruce Ashfield wrote: That's the kernel's configuration subsystem at play, it still has to process the the defconfig (which was placed as .config before starting the kernel build). Invalid options are removed, others are selected by Kconfigs, etc. So what you end up with is the processed .config and your old one in .config.old. Ah, OK, it's possible the option I wanted (CONFIG_REMOTEPROC) is not available for my machine (imx6/wandboard) and so removed. Where can I look to see if a config option is valid for a particular machine/architecture? I'm working on some patches that will show you that as part of the configuration audit task (there's potentially a library I can leverage) .. but for now, either looking at the Kconfig's or running menuconfig are the best (brute force) way to find what is missing. Bruce Thanks for the help. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] "bitbake meta-toolchain", QA Issue, library in wrong location
goofing around, did a "bitbake meta-toolchain" for my BBB configuration and, toward the end, got: WARNING: QA Issue: gcc-cross-canadian-arm-dbg: found library in wrong location: /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/.debug/libcc1.so.0.0.0 gcc-cross-canadian-arm-dbg: found library in wrong location: /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/.debug/libcc1plugin.so.0.0.0 gcc-cross-canadian-arm-dbg: found library in wrong location: /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/.debug/liblto_plugin.so.0.0.0 gcc-cross-canadian-arm: found library in wrong location: /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/libcc1.so.0.0.0 gcc-cross-canadian-arm: found library in wrong location: /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/libcc1.so gcc-cross-canadian-arm: found library in wrong location: /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/liblto_plugin.so.0 gcc-cross-canadian-arm: found library in wrong location: /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/libcc1plugin.so.0.0.0 gcc-cross-canadian-arm: found library in wrong location: /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/libcc1plugin.so.0 gcc-cross-canadian-arm: found library in wrong location: /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/liblto_plugin.so.0.0.0 gcc-cross-canadian-arm: found library in wrong location: /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/libcc1.so.0 gcc-cross-canadian-arm: found library in wrong location: /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/liblto_plugin.so gcc-cross-canadian-arm: found library in wrong location: /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/libcc1plugin.so [libdir] WARNING: QA Issue: nativesdk-qemu rdepends on nativesdk-libbz2, but it isn't a build dependency? [build-deps] is the above anything i need be concerned about? it's still baking so i haven't had a chance to test it yet. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] samhain: upgrade to 4.1.0
From: Li Xin
Also fix an error when "samhain -t check" is executed.
The error is like this:
'ERROR: msg=,
subroutine=, path=<(null)>'
Signed-off-by: Li Xin
---
.../samhain/{samhain-client_4.0.0.bb => samhain-client_4.1.0.bb}| 3 ++-
.../samhain/{samhain-server_4.0.0.bb => samhain-server_4.1.0.bb}| 0
recipes-security/samhain/samhain.inc| 6 +++---
3 files changed, 5 insertions(+), 4 deletions(-)
rename recipes-security/samhain/{samhain-client_4.0.0.bb =>
samhain-client_4.1.0.bb} (79%)
rename recipes-security/samhain/{samhain-server_4.0.0.bb =>
samhain-server_4.1.0.bb} (100%)
diff --git a/recipes-security/samhain/samhain-client_4.0.0.bb
b/recipes-security/samhain/samhain-client_4.1.0.bb
similarity index 79%
rename from recipes-security/samhain/samhain-client_4.0.0.bb
rename to recipes-security/samhain/samhain-client_4.1.0.bb
index c671b48..bb47449 100644
--- a/recipes-security/samhain/samhain-client_4.0.0.bb
+++ b/recipes-security/samhain/samhain-client_4.1.0.bb
@@ -8,7 +8,8 @@ EXTRA_OECONF += " \
--with-logserver=${SAMHAIN_SERVER} \
--with-port=${SAMHAIN_PORT} \
--with-config-file=/etc/samhainrc \
---with-data-file=/var/lib/samhain/samhain_file \
+--with-data-file=/var/samhain/samhain.data \
+--with-pid-file=/var/samhain/samhain.pid \
"
diff --git a/recipes-security/samhain/samhain-server_4.0.0.bb
b/recipes-security/samhain/samhain-server_4.1.0.bb
similarity index 100%
rename from recipes-security/samhain/samhain-server_4.0.0.bb
rename to recipes-security/samhain/samhain-server_4.1.0.bb
diff --git a/recipes-security/samhain/samhain.inc
b/recipes-security/samhain/samhain.inc
index e33182f..dedcf76 100644
--- a/recipes-security/samhain/samhain.inc
+++ b/recipes-security/samhain/samhain.inc
@@ -8,9 +8,8 @@ SRC_URI =
"http://la-samhna.de/archive/samhain_signed-${PV}.tar.gz \
file://${INITSCRIPT_NAME}.init \
file://${INITSCRIPT_NAME}.default \
"
-
-SRC_URI[md5sum] = "2144383cc5452b9b80c7e4e4c991ad4a"
-SRC_URI[sha256sum] =
"5a841708f78c6d9b4731970fa39151dff366885de08ecddc382e8c45a2c1b4e2"
+SRC_URI[md5sum] = "fcb59c6c8a1d30cc6ffc21557a0046d3"
+SRC_URI[sha256sum] =
"a8e10454782a7f3bb5f709dd05cee695ffbd052afc709668a3e7c4b629771189"
S = "${WORKDIR}/samhain-${PV}"
@@ -87,4 +86,5 @@ do_install_append () {
install -d ${D}${docdir}/${PN}
cp -r docs/* ${D}${docdir}/${PN}
cp -r scripts ${D}${docdir}/${PN}
+install -d -m 755 ${D}/var/samhain
}
--
1.8.4.2
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] To Specify the Linux Kernel Local Path In SRC_URI
Thank you khem..It worked. On 29-10-2015 11:19, Khem Raj wrote: On Wed, Oct 28, 2015 at 10:15 PM, YUKATHARSANI JEYACHANDRA wrote: Hi, I am trying to build kernel image for new hardware. So, I prefer to use my linux 3.x version with specific changes. I want bitbake to fetch the local path of my linux. Is it possible to specify the local path in SRC_URI. yes. use file:///path/to/linux.tar or even you can use externalsrc and point it to your tree during development. read through http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#building-software-from-an-external-source Thanks and Regards, Yukatharsani J. From: yocto-boun...@yoctoproject.org on behalf of Andres Sagot Sent: Thursday, October 29, 2015 9:49 AM To: yocto@yoctoproject.org Subject: [yocto] Kernel Version Dependency in BB Recipe Hello Yocto Community, I did a search and found a great deal about layer dependencies, but I am still not clear on how or if it is possible to add a kernel version dependency to a BB recipe. I would like to bitbake to report an error if it attempts to build my custom package with an unsupported version of Linux. Thank you and best regards, Andres -- ___ 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] [PATCH 1/1] prelink: AARCH64 support added
This patch adds support for prelinking in AARCH64.
To run prelink on successfully on target following changes are done
1. aarch64/dl-machine.h: Fix load-address for prelink support
https://sourceware.org/ml/libc-alpha/2015-10/msg00575.html
2. To handle relocation R_AARCH64_TLSDESC, Conflicts are raised for
R_AARCH64_TLSDESC.
Conflicts of relocation type R_AARCH64_TLSDESC is handled by
_dl_tlsdesc_undefweak which return the addend minus the thread pointer.
Hacked _dl_tlsdesc_undefweak to return addend only. Need to Fix this hack.
Signed-off-by: Vaneet Narang
Signed-off-by: Maninder Singh
---
trunk/src/Makefile.am|2 +-
trunk/src/arch-aarch64.c | 594 ++
trunk/src/dso.c |1 +
3 files changed, 596 insertions(+), 1 deletions(-)
create mode 100644 trunk/src/arch-aarch64.c
diff --git a/trunk/src/Makefile.am b/trunk/src/Makefile.am
index 7372fc1..d6cc5cb 100644
--- a/trunk/src/Makefile.am
+++ b/trunk/src/Makefile.am
@@ -24,7 +24,7 @@ bin_PROGRAMS = execstack
arch_SOURCES = arch-i386.c arch-alpha.c arch-ppc.c arch-ppc64.c \
arch-sparc.c arch-sparc64.c arch-x86_64.c arch-mips.c \
- arch-s390.c arch-s390x.c arch-arm.c arch-sh.c arch-ia64.c
+ arch-s390.c arch-s390x.c arch-arm.c arch-sh.c arch-ia64.c
arch-aarch64.c
common_SOURCES = checksum.c data.c dso.c dwarf2.c dwarf2.h fptr.c fptr.h \
hashtab.c hashtab.h mdebug.c prelink.h stabs.c crc32.c \
wrap-file.c canonicalize.c reloc-info.c reloc-info.h
diff --git a/trunk/src/arch-aarch64.c b/trunk/src/arch-aarch64.c
new file mode 100644
index 000..13713b2
--- /dev/null
+++ b/trunk/src/arch-aarch64.c
@@ -0,0 +1,594 @@
+/* Copyright (C) 2001, 2002, 2003, 2004, 2006, 2009 Red Hat, Inc.
+ Written by Jakub Jelinek , 2001.
+ Copyright (C) 2015 Samsung Electronics Co., Ltd. All rights reserved.
+ ARM64 support by Vaneet Narang
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software Foundation,
+ Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "prelink.h"
+
+/* The aarch64 ABI:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf
+ * documents a "class" value for specific reads and writes. All this
+ * indicates is that we should be using the ELFCLASS to determine if
+ * this should be a 32/64 bit read/write. (See table 4.9)
+ *
+ * We emulate this behavior below...
+ */
+#define read_uneclass(DSO, ADDR) \
+( gelf_getclass(DSO->elf) == ELFCLASS32 ? read_une32(DSO, ADDR) :
read_une64(DSO, ADDR) )
+
+#define write_neclass(DSO, ADDR, VAL) \
+( gelf_getclass(DSO->elf) == ELFCLASS32 ? write_ne32(DSO, ADDR, VAL) :
write_ne64(DSO, ADDR, VAL) )
+
+#define buf_write_neclass(DSO, BUF, VAL) \
+( gelf_getclass(DSO->elf) == ELFCLASS32 ? buf_write_ne32(DSO, BUF, VAL) :
buf_write_ne64(DSO, BUF, VAL) )
+
+static int
+aarch64_adjust_dyn (DSO *dso, int n, GElf_Dyn *dyn, GElf_Addr start,
+ GElf_Addr adjust)
+{
+int testec = addr_to_sec (dso, dyn->d_un.d_ptr);
+ if (dyn->d_tag == DT_PLTGOT)
+{
+ int sec = addr_to_sec (dso, dyn->d_un.d_ptr);
+ Elf64_Addr data;
+
+ if (sec == -1)
+ return 0;
+
+ data = read_une64 (dso, dyn->d_un.d_ptr);
+ /* If .got.plt[0] points to _DYNAMIC, it needs to be adjusted. */
+ if (data == dso->shdr[n].sh_addr && data >= start)
+ write_ne64 (dso, dyn->d_un.d_ptr, data + adjust);
+
+/* AARCH64 Hack start
+ *
+ * .got section entry is missing in .dynamic section
+ * .got section is previous to .got.plt section.
+ */
+ data = read_une64 (dso, dso->shdr[sec - 1].sh_addr);
+ if (data == dso->shdr[n].sh_addr && data >= start)
+ write_ne64 (dso, dso->shdr[sec - 1].sh_addr, data + adjust);
+/* AARCH64 Hack end*/
+
+ data = read_une64 (dso, dyn->d_un.d_ptr + 8);
+ /* If .got.plt[1] points to .plt + 0x16, it needs to be adjusted. */
+ if (data && data >= start)
+ {
+ int i;
+
+ for (i = 1; i < dso->ehdr.e_shnum; i++)
+ if (data == dso->shdr[i].sh_addr
+ && dso->shdr[i].sh_type == SHT_PROGBITS
+ && strcmp (strptr (dso, dso->ehdr.e_shstrndx,
+ dso->shdr[i].sh_n
