Re: [yocto] libgcc_s not present in Yocto image

Hi Khem Thanks for trying to help :-) I read what you have suggested below as trying to execute “ld.so” and passing my program as an argument. I can’t find a file called “ld.so” on either my Yocto image, or even the Ubuntu box that I am using to build it (which I use as a comparative

[linux-yocto] [PATCH 05/29] i2c: core: fix typo in comment

From: Shailendra Verma Signed-off-by: Shailendra Verma Signed-off-by: Wolfram Sang Upstream-status: Backport Signed-off-by: Saul Wold --- drivers/i2c/i2c-core.c | 2 +- 1 file changed,

[linux-yocto] [PATCH 04/29] i2c: check for proper length of the reg property

From: Wolfram Sang int is vague, let's simply use the type of the variable in question. Signed-off-by: Wolfram Sang Reviewed-by: Simon Horman Signed-off-by: Wolfram Sang

[linux-yocto] [PATCH 00/29] Backports and other features for Galileo

Bruce, This is a set of patches that are currently being maintained in the meta-intel-galileo BSP which we are working to merge into meta-intel proper. These include items that are backported from newer versions as well as some galileo specific items. There is one ARM patch that touches i2c

[linux-yocto] [PATCH 07/29] i2c: core: only use set_scl for bus recovery after calling prepare_recovery

From: Jan Luebbe Using set_scl may be ineffective before calling the driver specific prepare_recovery callback, which might change into a test mode. So instead of setting SCL in i2c_generic_scl_recovery, move it to i2c_generic_recovery (after the optional prepare_recovery).

[linux-yocto] [PATCH 10/29] GPIO / ACPI: export acpi_gpiochip_request(free)_interrupts for module use

From: Hanjun Guo acpi_gpiochip_request(free)_interrupts can be used for modules, so export them. This also fixs a compile error when xgene-sb configured as kernel module. Fixes: 733cf014f020 "gpio: xgene: add ACPI support for APM X-Gene GPIO standby driver" Reviewed-by:

Re: [yocto] libgcc_s not present in Yocto image

On 5 February 2016 at 15:24, Nathan Sowatskey wrote: > I suspect that my test program, which was supplied to me as a .deb > package, was compiled on Ubuntu, and so links to libgcc_s.so.1. I can’t see > any obvious way to get libgcc_s.so.1 on Yocto. I already have: > libgcc

Re: [yocto] [PATCH][yocto-autobuilder] nightly-musl: also build core-image-weston

On 5 February 2016 at 09:02, Burton, Ross wrote: > We can switch nightly-musl over to just opkg whilst rpm is known to be > broken. We already have a separate tiny buildset. > Revised patch sent. Ross -- ___ yocto mailing

[linux-yocto] [PATCH 02/29] i2c / ACPI: Assign IRQ for devices that have GpioInt automatically

From: Mika Westerberg Following what DT already does. If the device does not have ACPI Interrupt resource but instead it has one or more GpioInt resources listed below it, we take the first GpioInt resource, convert it to suitable Linux IRQ number and pass it to

[linux-yocto] [PATCH 06/29] i2c: core: Reduce stack size of acpi_i2c_space_handler()

From: Jarkko Nikula sizeof(struct i2c_client) is 1088 bytes on a CONFIG_X86_64=y build and produces following warning when CONFIG_FRAME_WARN is set to 1024: drivers/i2c/i2c-core.c: In function ‘acpi_i2c_space_handler’: drivers/i2c/i2c-core.c:367:1: warning: the

[linux-yocto] [PATCH 01/29] i2c / ACPI: Use 0 to indicate that device does not have interrupt assigned

From: Mika Westerberg This is the convention used in most parts of the kernel including DT counterpart of I2C slave enumeration. To make things consistent do the same for ACPI I2C slave enumeration path as well. Signed-off-by: Mika Westerberg

[yocto] Yocto Project Status WW06

Current Dev Position: YP 2.1 M3 Next Deadline: YP 2.1 M2 Target release date is February 12, 2016 SWAT team rotation: Alejandro Franco -> Juro https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: * YP 2.1 M2-rc1 QA report has been published. The number of

[linux-yocto] [PATCH 12/29] i2c / ACPI: Rework I2C device scanning

From: Mika Westerberg The way we currently scan I2C devices behind an I2C host controller does not work in cases where the I2C device in question is not declared directly below the host controller ACPI node. This is perfectly legal according the ACPI 6.0

[linux-yocto] [PATCH 13/29] mfd: core: redo ACPI matching of the children devices

From: Andy Shevchenko There is at least one board on the market, i.e. Intel Galileo Gen2, that uses _ADR to distinguish the devices under one actual device. Due to this we have to improve the quirk in the MFD core to handle that board. Signed-off-by: Andy

[linux-yocto] [PATCH 03/29] i2c: slave: add error messages to slave core

From: Wolfram Sang Inform users what went wrong from the core, so drivers don't have to do it. Signed-off-by: Wolfram Sang Acked-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang

[linux-yocto] [PATCH 09/29] gpio / ACPI: Add support for retrieving GpioInt resources from a device

From: Mika Westerberg ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter is used to describe that a given device interrupt line is connected to a specific GPIO pin. Typical ACPI _CRS entry for such device looks like below: Name

[linux-yocto] [PATCH 08/29] i2c: fix leaked device refcount on of_find_i2c_* error path

From: Vladimir Zapolskiy If of_find_i2c_device_by_node() or of_find_i2c_adapter_by_node() find a device by node, but its type does not match, a reference to that device is still held. This change fixes the problem. Signed-off-by: Vladimir Zapolskiy

[linux-yocto] [PATCH 11/29] gpio / ACPI: Return -EPROBE_DEFER if the gpiochip was not found

From: Mika Westerberg If a driver requests a GPIO described in its _CRS but the GPIO host controller (gpiochip) driver providing the GPIO has not been loaded yet acpi_get_gpiod() returns -ENODEV which causes the calling driver to fail. If the gpiochip driver is

Re: [yocto] libQt5Network.so.5 - How does one get that please?

Did you try $ ldd program-name This should tell you which libraries are missing and where it is looking. Then you can do: $ find / -name libname.so To find them. Finally, you can fix your /etc/ld.so.conf with the path to your libs. Then do $ ldconfig # refresh library cache so your

[linux-yocto] [PATCH 20/29] acpi: added a custom DSDT file.

From: Ismo Puustinen The file has fixed GPIO IRQ assignment. Upstream-status: Inappropriate, custom firmware Signed-off-by: Saul Wold --- include/DSDT.hex | 1160 ++ 1 file changed, 1160

Re: [yocto] libgcc_s not present in Yocto image

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

Re: [yocto] libgcc_s not present in Yocto image

On Fri, 2016-02-05 at 15:50 +, Burton, Ross wrote: > > On 5 February 2016 at 15:24, Nathan Sowatskey > wrote: > > I suspect that my test program, which was supplied to me as a .deb > > package, was compiled on Ubuntu, and so links to libgcc_s.so.1. I > > can’t see any

[linux-yocto] [PATCH 22/29] pca9685: PCA9685 PWM and GPIO multi-function device.

From: Josef Ahmad There is also a driver for the same chip in drivers/pwm. This version has support for setting the output in GPIO mode in addition to the PWM mode. Upstream-status: Pending Signed-off-by: Saul Wold --- drivers/mfd/Kconfig

[linux-yocto] [PATCH 25/29] staging:iio: add support for ADC1x8s102.

From: Todor Minchev Upstream-status: Pending Signed-off-by: Saul Wold --- drivers/staging/iio/adc/Kconfig | 13 ++ drivers/staging/iio/adc/Makefile | 1 + drivers/staging/iio/adc/adc1x8s102.c | 387

[linux-yocto] [PATCH 21/29] gpio: pca953x: provide GPIO base based on _UID

From: Andy Shevchenko Custom kernel for Intel Galileo Gen2 provides and moreover libmraa relies on the continuous GPIO space. To do such we have to configure GPIO base per each GPIO expander. The only value we can use is the ACPI _UID. Signed-off-by: Andy

[linux-yocto] [PATCH 26/29] adc1x8s102: support ACPI-based enumeration.

From: Ismo Puustinen Upstream-status: Pending Signed-off-by: Saul Wold --- drivers/staging/iio/adc/adc1x8s102.c | 76 ++-- 1 file changed, 63 insertions(+), 13 deletions(-) diff --git

[linux-yocto] [PATCH 24/29] spi-pxa2xx: fixed ACPI-based enumeration of SPI devices.

From: Ismo Puustinen Slave devices were not enumerated by ACPI data because the ACPI handle for the spi-pxa2xx controller was NULL if it was itself enumerated by PCI. Upstream-status: Inappropriate, real fix forthcoming Signed-off-by: Saul Wold

[linux-yocto] [PATCH 27/29] gpio-pca953x: add "drive" property.

From: Ismo Puustinen Galileo gen 2 has support for setting GPIO modes. Expose these properties through the GPIO sysfs interface. This approach is bit hacky, since it changes the interface semantics. The original patch was by Josef Ahmad

[linux-yocto] [PATCH 28/29] iio: light: add support for ROHM BH1710/BH1715/BH1721/BH1750/BH1751 ambient light sensors

From: Tomasz Duszynski Add support for ROHM BH1710/BH1715/BH1721/BH1750/BH1751 ambient light sensors. Signed-off-by: Tomasz Duszynski Signed-off-by: Jonathan Cameron Signed-off-by: Saul Wold ---

Re: [yocto] libgcc_s not present in Yocto image

by ld.so I mean dynamic linker shared lib not literally ld.so file it should be in /lib/ld*.so On Fri, Feb 5, 2016 at 11:36 PM, Nathan Sowatskey wrote: > Hi Khem > > Thanks for trying to help :-) > > I read what you have suggested below as trying to execute “ld.so” and passing

Re: [yocto] libgcc_s not present in Yocto image

Hi Khem Thanks for trying to help :-) I read what you have suggested below as trying to execute “ld.so” and passing my program as an argument. I can’t find a file called “ld.so” on either my Yocto image, or even the Ubuntu box that I am using to build it (which I use as a comparative

Re: [yocto] libgcc_s not present in Yocto image

The results should tell us: $ files /usr/bin/testprog What are they? (Sitting on the edge of my seat.) From: Nathan Sowatskey Sent: Friday, February 5, 2016 10:09 AM To: Fred Ollinger Cc: Burton, Ross; yocto@yoctoproject.org Subject:

Re: [yocto] libgcc_s not present in Yocto image

Thanks Khem. Please see below: readelf -a /usr/bin/testprog ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1

Re: [yocto] libgcc_s not present in Yocto image

Thanks guys :-) Suggestions played out below. find /lib -name libgcc_s.so.1 /lib/libgcc_s.so.1 So, that *is* there. Doh! file /usr/bin/testprog /usr/bin/testprog: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux

Re: [yocto] libgcc_s not present in Yocto image

What's the result of: $ cat /proc/cpuinfo (So far, it seems like my hunch was wrong.) Frederick From: Nathan Sowatskey Sent: Friday, February 5, 2016 10:12 AM To: Fred Ollinger Cc: Burton, Ross; yocto@yoctoproject.org Subject: Re:

Re: [yocto] libgcc_s not present in Yocto image

On Fri, Feb 5, 2016 at 10:23 AM, Nathan Sowatskey wrote: > Hi Kem > > The testprog was given to me as a .deb package by a third party to test. I > did not compile it and I don’t know what they did either. OK, paste the out of readelf -a on this binary its mosly looking for

Re: [yocto] libgcc_s not present in Yocto image

On 5 February 2016 at 17:47, Nathan Sowatskey wrote: > find /usr/lib -name libgcc_s.so.1 > root@qemux86-64:~# > > I don’t have that lib. > As I said, libgcc_s.so.1 is in /lib, not /usr/lib. > With ldd I get: > > ldd /usr/bin/testprog > /usr/bin/ldd: line 117:

Re: [yocto] libgcc_s not present in Yocto image

My guess is that the executable is not compiled for his hardware. Frederick From: Burton, Ross Sent: Friday, February 5, 2016 9:56 AM To: Nathan Sowatskey Cc: yocto@yoctoproject.org; Fred Ollinger Subject: Re: [yocto] libgcc_s not present

Re: [yocto] libgcc_s not present in Yocto image

file /usr/bin/testprog /usr/bin/testprog: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=26317096ed83d21bc6808f0d2d47b12de1ab31ce, not stripped Thoughts? > On 5 Feb 2016, at 19:10, Fred

[yocto] Release Candidate Build for yocto-2.0.1.rc4.rc4 now available.

A release candidate build for yocto-2.0.1.rc4 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.0.1.rc4 Please begin QA on this build as soon as possible. Build hash information: meta-intel : 4e87c59bdedaa8c3e44fc02fd23be726c4d1dfb9 meta-fsl-arm :

Re: [yocto] libgcc_s not present in Yocto image

Thanks Fred. I am using qemux86_64 on Intel i7 chips with OSX. The target is likewise Intel. I am assuming that is quite generic, but … Regards Nathan > On 5 Feb 2016, at 19:06, Fred Ollinger wrote: > > My guess is that the executable is not compiled for his

Re: [yocto] libgcc_s not present in Yocto image

Thanks for trying :-) cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : QEMU Virtual CPU version 2.5+ stepping: 3 cpu MHz : 2394.533 cache size : 512 KB physical id : 0 siblings: 1 core

Re: [yocto] libgcc_s not present in Yocto image

Hi Ross Many thanks for following up. Fred also offered some helpful suggestions in a different thread. The program in question was supplied to me by a third party for testing, so I shall obscure the name here and call it testprog. It was installed by: dpkg -i ./testprog.deb Where the

Re: [yocto] libgcc_s not present in Yocto image

On Fri, Feb 5, 2016 at 10:12 AM, Nathan Sowatskey wrote: > file /usr/bin/testprog > /usr/bin/testprog: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux > 2.6.24,

Re: [yocto] libgcc_s not present in Yocto image

What are results of: $ file testprog Frederick From: Nathan Sowatskey Sent: Friday, February 5, 2016 9:47 AM To: Burton, Ross Cc: yocto@yoctoproject.org; Fred Ollinger Subject: Re: [yocto] libgcc_s not present in Yocto image Hi Ross

Re: [yocto] libgcc_s not present in Yocto image

Hi Kem The testprog was given to me as a .deb package by a third party to test. I did not compile it and I don’t know what they did either. Regards Nathan > On 5 Feb 2016, at 19:21, Khem Raj wrote: > > On Fri, Feb 5, 2016 at 10:12 AM, Nathan Sowatskey

[yocto] What is the correct way to get a list of package run-time dependencies during the build process?

Hi, I noticed that during the build bitbake supplies you rather correct (if it is correct in the recipe) list of recipe build-time dependencies. However, this isn't true for run-time dependencies. Moreover it seems that when you define a recipe you don't have to list run-time dependencies, but

Re: [yocto] Signed RPMs

Hi Chris, On 04/02/16 23:57, "Chris Trobridge" wrote: >Hi, >I have been testing out the facility for generating signed RPMs. > >It's currently failing to find >'build/tmp/sysroots/x86_64-linux/etc/RPM-GPG-PUBKEY', log

[linux-yocto] [PATCH 16/29] gpio: pca953x: store driver_data for future use

From: Andy Shevchenko Instead of using id->driver_data directly we copied it to the internal structure. This will help to adapt driver for ACPI use. Signed-off-by: Andy Shevchenko Upstream-status: Submitted Signed-off-by:

[linux-yocto] [PATCH 19/29] pwm-pca9685: enable ACPI device found on Galileo Gen2

From: Andy Shevchenko There is a chip connected to i2c bus on Intel Galileo Gen2 board. Enable it via ACPI ID INT3492. Cc: Thierry Reding Signed-off-by: Andy Shevchenko Upstream-status: Submitted

[linux-yocto] [PATCH 14/29] mfd: intel_quark_i2c_gpio: load gpio driver first

From: Andy Shevchenko On Intel Galileo boards the GPIO expander is connected to i2c bus. Moreover it is able to generate interrupt, but interrupt line is connected to GPIO. That's why we have to have GPIO driver in place when we will probe i2c host with device

[linux-yocto] [PATCH 15/29] mfd: intel_quark_i2c_gpio: support devices behind i2c bus

From: Andy Shevchenko On Intel Galileo Gen2 the GPIO expanders are connected to the i2c bus. For those devices the ACPI table has specific parameters that refer to an actual i2c host controller. Since MFD now copes with that specific configuration we have to

[linux-yocto] [PATCH 17/29] gpio: pca953x: support ACPI devices found on Galileo Gen2

From: Andy Shevchenko This patch adds a support of the expandes found on Intel Galileo Gen2 board. The platform information comes from ACPI. Signed-off-by: Andy Shevchenko Upstream-status: Submitted Signed-off-by: Saul Wold

[linux-yocto] [PATCH 18/29] at24: enable ACPI device found on Galileo Gen2

From: Andy Shevchenko There is a 24c08 chip connected to i2c bus on Intel Galileo Gen2 board. Enable it via ACPI ID INT3499. Signed-off-by: Andy Shevchenko Upstream-status: Submitted Signed-off-by: Saul Wold

Re: [yocto] libgcc_s not present in Yocto image

Thank you Burton and Tanu. The upshot here seems to be that there is a platform dependency on whether one links to libgcc_s.a or libgcc_s.so.1: "libgcc.a or libgcc_s.so.1 on some platforms”. I suspect that my test program, which was supplied to me as a .deb package, was compiled on Ubuntu, and

[yocto] [PATCH][yocto-autobuilder] nightly-musl: build core-image-weston, only use ipkg

Build core-image-weston for more coverage, and use ipkg explicitly as rpm is known to break with musl. Signed-off-by: Ross Burton --- buildset-config.controller/nightly-musl.conf | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [yocto] libgcc_s not present in Yocto image

On 5 February 2016 at 18:12, Nathan Sowatskey wrote: > interpreter /lib64/ld-linux-x86-64.so.2 Does the loader hunt around for this, as this is certainly not present in a default OE image? Ross -- ___ yocto mailing list

Re: [yocto] libgcc_s not present in Yocto image

On Fri, Feb 5, 2016 at 11:53 AM, Burton, Ross wrote: > > On 5 February 2016 at 18:12, Nathan Sowatskey wrote: >> >> interpreter /lib64/ld-linux-x86-64.so.2 > > > Does the loader hunt around for this, as this is certainly not present in a > default OE

Re: [yocto] libgcc_s not present in Yocto image

On Fri, Feb 5, 2016 at 12:46 PM, Burton, Ross wrote: > > On 5 February 2016 at 19:56, Khem Raj wrote: >> >> >> interpreter /lib64/ld-linux-x86-64.so.2 >> > >> > >> > Does the loader hunt around for this, as this is certainly not present >> > in a >> >

Re: [yocto] libgcc_s not present in Yocto image

On 5 February 2016 at 19:56, Khem Raj wrote: > >> interpreter /lib64/ld-linux-x86-64.so.2 > > > > > > Does the loader hunt around for this, as this is certainly not present > in a > > default OE image? > > no it wont. infact thats the loader. Yeah, what I meant is would the

Re: [yocto] libQt5Network.so.5 - How does one get that please?

It turns out that the build is correct, in that the libraries are there, but the test program I am using is not finding them :-/ So, for future reference, at least part what is required to work is correct in my build. Regards Nathan > On 4 Feb 2016, at 17:39, Nathan Sowatskey

Re: [yocto] What is the correct way to get a list of package run-time dependencies during the build process?

On 5 February 2016 at 08:27, Reshetova, Elena wrote: > I noticed that during the build bitbake supplies you rather correct (if it > is correct in the recipe) list of recipe build-time dependencies. However, > this isn’t true for run-time dependencies. Moreover it seems

Re: [yocto] [PATCH][yocto-autobuilder] nightly-musl: also build core-image-weston

On 5 February 2016 at 02:08, Khem Raj wrote: > > diff --git a/buildset-config.controller/nightly-musl.conf > b/buildset-config.controller/nightly-musl.conf > > index 9a82e6b..5da90c3 100644 > > --- a/buildset-config.controller/nightly-musl.conf > > +++

Re: [yocto] What is the correct way to get a list of package run-time dependencies during the build process?

On 5 February 2016 at 08:27, Reshetova, Elena < elena.reshet...@intel.com> wrote: I noticed that during the build bitbake supplies you rather correct (if it is correct in the recipe) list of recipe build-time dependencies. However, this isn’t true for

[yocto] libgcc_s not present in Yocto image

Hi I am working with a test program which has a dependency on libgcc_s. On Ubuntu that is available, for example from a 14.04 Ubuntu desktop build: find /usr/lib -name "*gcc*” ... /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_s.so ... On the Yocto image I am building (see below for conf files), I

Re: [yocto] libgcc_s not present in Yocto image

On Fri, 2016-02-05 at 12:40 +0100, Nathan Sowatskey wrote: > Hi > > I am working with a test program which has a dependency on libgcc_s.  > > On Ubuntu that is available, for example from a 14.04 Ubuntu desktop build: > > find /usr/lib -name "*gcc*” > ... >

Re: [yocto] libgcc_s not present in Yocto image

On 5 February 2016 at 11:40, Nathan Sowatskey wrote: > Is there a way to get the libgcc_s library on a Yocto image? Is that even > the right thing to do? > It's fairly likely that your binary is actually linking to libgcc_s.so.1 (which by default is in /lib, part of libgcc).

Re: [yocto] What is the correct way to get a list of package run-time dependencies during the build process?

On 5 February 2016 at 08:27, Reshetova, Elena < elena.reshet...@intel.com> wrote: I noticed that during the build bitbake supplies you rather correct (if it is correct in the recipe) list of recipe build-time dependencies. However, this isn’t true for

Re: [yocto] Signed RPMs

On 05/02/16 11:15, "Chris Trobridge" wrote: >> Date: Fri, 5 Feb 2016 10:00:50 +0200 >> Subject: Re: [yocto] Signed RPMs >> From: markus.lehto...@linux.intel.com >> To: christrobri...@hotmail.com; yocto@yoctoproject.org >> >> Hi Chris, >> >> ... >> >> That really