[yocto] [meta-security][PATCH] Fix a trousers build on when not in use systemd: unparsed line: 'inherit'

[Thomas Perrot]

Signed-off-by: Thomas Perrot 
---
 recipes-tpm/trousers/trousers_0.3.13.bb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/recipes-tpm/trousers/trousers_0.3.13.bb 
b/recipes-tpm/trousers/trousers_0.3.13.bb
index e274972..6853f18 100644
--- a/recipes-tpm/trousers/trousers_0.3.13.bb
+++ b/recipes-tpm/trousers/trousers_0.3.13.bb
@@ -16,8 +16,7 @@ SRC_URI = 
"http://sourceforge.net/projects/trousers/files/${BPN}/${PV}/${BPN}-${
 SRC_URI[md5sum] = "ad508f97b406f6e48cd90e85d78e7ca8"
 SRC_URI[sha256sum] = 
"bb908e4a3c88a17b247a4fc8e0fff3419d8a13170fe7bdfbe0e2c5c082a276d3"
 
-inherit autotools pkgconfig useradd update-rc.d
-inherit 
${@bb.utils.contains('VIRTUAL-RUNTIME_init_manager','systemd','systemd','', d)}
+inherit autotools pkgconfig useradd update-rc.d 
${@bb.utils.contains('VIRTUAL-RUNTIME_init_manager','systemd','systemd','', d)}
 
 PACKAGECONFIG ?= "gmp "
 PACKAGECONFIG[gmp] = "--with-gmp, --with-gmp=no, gmp"
-- 
2.1.4

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

[yocto] Is it possible to install *.deb file directly in the yocto platform?

[윤영석]

hi,
 
i just want to install some deb file, Is it possible?
 
thanks.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [genericx86-jethro] core-image-sato HDDIMG 'install' - no hard drive selected - /etc/fstab no such file or directory

[Simon Bolek]

Hi Raj,
Thank you.
I have already tried this.

I managed to start the USB installation by addding
kernel-modules
to core-image-minimal-initramfs.bb

However after the installation, system will not boot up due to kernel
panic:
VFS: Cannot open root device "sda2" or unknown block (0,0) Please append a
correct "root=" boot option;

It seems, the SDD hard drive is found on installation time, but not on boot
time.
How is that possible? It did work with FIDO, but is not working with JETHRO.
Any hint what I have to look for now? Is it the drivers missing? Or maybe
some scripts not running at boot?
What will run at boot prior to mounting what is stated in root= in grub.cfg?

kind regards
Simon :-)


On Sat, Jul 16, 2016 at 2:02 AM, Khem Raj  wrote:

> On Fri, Jul 15, 2016 at 3:17 PM, Simon Bolek 
> wrote:
> > Hi Raj,
> >
> > Maybe you could help me with this.
> > I found out that during rootfs (meta/lib/oe/rootfs.py), depmodwrapper
> script
> > is beeing called.
> > I noticed, that it does generate /lib/modules/.. directory
> structure
> > under:
> > poky/build/tmp/work/genericx86-poky-linux/core-image-sato
> > However, at the end of the bitbake process, there is no /lib/modules
> > direcotry in
> > core-image-minimal-initramfs-genericx86-20160715210400.rootfs.cpio.gz
> >
> > Where are the steps, where this .cpio.gz file is beeing generated. There
> > must be a place where all the files, that are inside, are beeing put
> > together.
>
> initramfs image is a separate image. What you are seeing is the final
> image.
> you might have to add the kernel module to you machine conf
>
> MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
>
> >
> > HELP!
> > kind regards
> > Simon :-)
> >
> >
> >
> > On Fri, Jul 15, 2016 at 10:59 AM, Simon Bolek <
> simon.bo...@googlemail.com>
> > wrote:
> >>
> >> Thanks, but neither:
> >> pkg_postinst_kernel-base ()
> >> nor:
> >> pkg_postinst_kernel-image ()
> >> from /meta/classes/kernel.bbclass gets called when running:
> >> - bitbake core-image-sato or
> >> - bitbake linux-yocto
> >>
> >> I put some commands in there, which are definitely wrong (like foobar)
> and
> >> bitbake run successfully.
> >> Whereas, in other funtions it caused problems.
> >> Any ideas how can fix this?
> >>
> >> thanks and best regards
> >> Simon :-)
> >>
> >>
> >> On Fri, Jul 15, 2016 at 1:30 AM, Khem Raj  wrote:
> >>>
> >>> On Thu, Jul 14, 2016 at 4:16 PM, Simon Bolek <
> simon.bo...@googlemail.com>
> >>> wrote:
> >>> > Hi Raj,
> >>> >
> >>> > About depmod again.
> >>> > Should it be run from meta/classes/kernel.bbclass  ?
> >>> > ...
> >>> > pkg_postinst_kernel-base () {
> >>> > if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
> >>> > mkdir -p $D/lib/modules/${KERNEL_VERSION}
> >>> > fi
> >>> > if [ -n "$D" ]; then
> >>> > depmodwrapper -a -b $D ${KERNEL_VERSION}
> >>> > else
> >>> > depmod -a ${KERNEL_VERSION}
> >>> > fi
> >>> > }
> >>> > ...
> >>> >
> >>> > Where is this function beeing called?
> >>>
> >>> It should be called during rootfs and image creation time. as well as
> >>> when you update the package using online package manager.
> >>>
> >>> > I did not find it anywhere.
> >>> > thanks and kind regards
> >>> > Simon :-)
> >>> >
> >>> > On Thu, Jul 14, 2016 at 8:32 AM, Simon Bolek
> >>> > 
> >>> > wrote:
> >>> >>
> >>> >>
> >>> >> On Wed, Jul 13, 2016 at 4:56 PM, Khem Raj 
> wrote:
> >>> >>>
> >>> >>> On Wed, Jul 13, 2016 at 4:57 AM, Simon Bolek
> >>> >>> 
> >>> >>> wrote:
> >>> >>> > Hi Raj,
> >>> >>> >
> >>> >>> > So i tried to do manually, what init script does and udev
> >>> >>> > definitely
> >>> >>> > does
> >>> >>> > not recognize the SSD drive.
> >>> >>> > I ran
> >>> >>> >  /lib/udev/udevd --daemon --debug > udev.debug 2>&1 &
> >>> >>> > from the cli and there is no trace of recognizing the SSD. Only
> the
> >>> >>> > /dev/sda, which is the USB stick I am running the installation
> >>> >>> > from.
> >>> >>> >
> >>> >>> > I used 'meld' to compare the /initrd from current jethro image
> and
> >>> >>> > previous
> >>> >>> > working fido image.
> >>> >>> > They are almost the same:
> >>> >>> > - in jethro /lib/modules... file structure is missing with:
> >>> >>> > modules.alias
> >>> >>> > modules.alias.bin
> >>> >>> > modules.builtin.bin
> >>> >>> > modules.dep
> >>> >>> > modules.dep.bin
> >>> >>> > modules.devname
> >>> >>> > modules.softdep
> >>> >>> > modules.symbols
> >>> >>> > modules.symbols.bin
> >>> >>>
> >>> >>> this means depmod did not run during initramfs image creation
> >>> >>
> >>> >> How can I make this happen during bitbake, so i have those files in
> >>> >> the
> >>> >> HDDIMG?
> >>> >>
> >>> >>>
> >>> >>> >
> >>> >>> > - there are slight differences between
> >>> >>> > /etc/init.d/udev
> >>> >>> > /etc/udev/scripts/mount.sh
> >>> >>> > , but I cannot tell, if this is the reason.
> >>> >>>
> >>> >>> what are the differences ?
> >>> >>
> >>> >>
> >>> >> Sorry for this patch-like copy/paste, but this was the simplest way
> of
> >>> >

[yocto] populate_sdk and external toolchain

[Manish Jaggi]

I am trying to build sdk (using populate_sdk option).
Toolchain being used is an external one.

When I run bitbake core-image-minimal -c populate_sdk, I get the below error

| checking for x86_64-pokysdk-linux-gcc...  
/home/manish/poky/build/tmp/work/x86_64-linux/gcc-crosssdk-initial-x86_64/5.2.0-r0/gcc-5.2.0/build.x86_64-linux.x86_64-pokysdk-linux/./gcc/xgcc
-B/home/manish/poky/build/tmp/work/x86_64-linux/gcc-crosssdk-initial-x86_64/5.2.0-r0/gcc-5.2.0/build.x86_64-linux.x86_64-pokysdk-linux/./gcc/
-B/home/manish/poky/build/tmp/sysroots/x86_64-linux/usr/x86_64-pokysdk-linux/bin/
 
-B/home/manish/poky/build/tmp/sysroots/x86_64-linux/usr/x86_64-pokysdk-linux/lib/
 -isystem
/home/manish/poky/build/tmp/sysroots/x86_64-linux/usr/x86_64-pokysdk-linux/include
 -isystem 
/home/manish/poky/build/tmp/sysroots/x86_64-linux/usr/x86_64-pokysdk-linux/sys-include
--sysroot=/home/manish/poky/build/tmp/work/x86_64-linux/gcc-crosssdk-initial-x86_64/5.2.0-r0/gcc-5.2.0/build.x86_64-linux.x86_64-pokysdk-linux/tmpsysroot
| checking for suffix of object files... configure: error: in
`/home/manish/poky/build/tmp/work/x86_64-linux/gcc-crosssdk-initial-x86_64/5.2.0-r0/gcc-5.2.0/build.x86_64-linux.x86_64-pokysdk-linux/x86_64-pokysdk-linux/libgcc':
| configure: error: cannot compute suffix of object files: cannot compile

Is it possible to remove gcc-crosssdk from populate_sdk script ?



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

[yocto] [meta-raspberrypi][PATCH v4 00/12] Support for VC4 graphics driver

[Herve Jourdain]

v4 series:
a. rebased
b. Upstream-Status added to the patch to the VC4 driver (needed only for kernel 
4.4, accepted upstream in 4.7)

v3 series:
a. patch rebased
b. new revision of kernel, to get a version of the VC4 graphics driver that 
handles render nodes
c. patch to the VC4 driver to enable proper working of the render nodes (need 
to add authorization for IOCTLs)

v2 series:
a. Fix the 4.4.10 kernel revision
b. Effectively add vc4-kms-v3d overlay to the list of overlays to build 
(forgotten previously)
c. Make the parameter to the v4c-kms-v3d overlay configurable
d. Add default values for the cma parameter to the v4c-kms-v3d overlay, 
depending on the board (and the memory it has)

This patch series enables the support for the VC4 graphics driver from Eric 
Anholt.
There was a previous patch series by Javier Martinez Canillas, but it required 
use of a different kernel.
VC4 is now supported in the raspberrypi official kernel, at least for 4.4.9+.
The support in 4.1 exists, but it is NOT STABLE, so it has been deemed 
unreasonable to support VC4 with 4.1 kernels.

THEREFORE, VC4 graphics is supported ONLY for kernel versions 4.4.9 and later.

This patch series proposes to support VC4 by only adding 'vc4graphics' to 
MACHINE_FEATURES, for raspberrypi. If this is set, it will trigger all the 
necessary configuration/changes to use the VC4 driver, including 
mesa/wayland/weston currently, and adding the overlay required.
In order for this series to work, some previous patches are needed (support for 
.dtbo, and fix of the mesa packaging when there is no DRI driver).
The memory reserved for the VC4 driver has default values depending on the 
version of the board used, but it can be configured by setting VC4_CMA_SIZE to 
a value supported by the overlay ('cma-256', 'cma-192', 'cma-128', 'cma-96', 
'cma-64').
'cma-256' is the recommended value, but it might not be possible on boards with 
512MB or DRAM, or less...
'cma-64' is known to not being able to support FHD/1080p.

It was tested with wayland/weston, without the support for X11.

This patch series depends on two other patch series previously posted, that 
enable the support for .dtbo overlay files.

Herve Jourdain (12):
  rpi-default-providers.inc: change default providers to support
vc4graphics
  rpi-base.inc: add vc4-kms-v3d to the overlays to support vc4graphics
  raspberrypi.conf: set the default value of VC4_CMA_SIZE to support
vc4graphics
  raspberrypi0.conf: set the default value of VC4_CMA_SIZE to support
vc4graphics
  raspberrypi2.conf: set the default value of VC4_CMA_SIZE to support
vc4graphics
  raspberrypi3.conf: set the default value of VC4_CMA_SIZE to support
vc4graphics
  rpi-config_git.bb: add v4c overlay to config.txt to support
vc4graphics
  wayland/weston_%.bbappend: modify configuration options to support
vc4graphics
  weston/weston_%.bbappend: modify configuration options to support
vc4graphics
  mesa_%.bbappend: new file to add the correct configuration options to
support vc4graphics
  linux-rpi.inc: add the configuration options required to support
vc4graphics
  linux-raspberrypi-4.4: add patch to enable proper operation of
renderD128 device

 conf/machine/include/rpi-base.inc  |  1 +
 conf/machine/include/rpi-default-providers.inc |  8 +++---
 conf/machine/raspberrypi.conf  |  2 ++
 conf/machine/raspberrypi0.conf |  2 ++
 conf/machine/raspberrypi2.conf |  2 ++
 conf/machine/raspberrypi3.conf |  2 ++
 recipes-bsp/bootfiles/rpi-config_git.bb| 10 +++-
 recipes-graphics/mesa/mesa_%.bbappend  |  4 +++
 recipes-graphics/wayland/weston_%.bbappend |  6 ++---
 recipes-graphics/weston/weston_%.bbappend  | 13 +-
 .../0002-vc4-ioctl-rendering-allow.patch   | 29 ++
 recipes-kernel/linux/linux-raspberrypi_4.4.bb  |  1 +
 recipes-kernel/linux/linux-rpi.inc | 10 
 13 files changed, 75 insertions(+), 15 deletions(-)
 create mode 100644 recipes-graphics/mesa/mesa_%.bbappend
 create mode 100644 
recipes-kernel/linux/linux-raspberrypi-4.4/0002-vc4-ioctl-rendering-allow.patch

-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH v4 01/12] rpi-default-providers.inc: change default providers to support vc4graphics

[Herve Jourdain]

Signed-off-by: Herve Jourdain 
---
 conf/machine/include/rpi-default-providers.inc | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/conf/machine/include/rpi-default-providers.inc 
b/conf/machine/include/rpi-default-providers.inc
index 359870d..078e9d6 100644
--- a/conf/machine/include/rpi-default-providers.inc
+++ b/conf/machine/include/rpi-default-providers.inc
@@ -2,8 +2,8 @@
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-raspberrypi"
 PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
-PREFERRED_PROVIDER_virtual/egl ?= "userland"
-PREFERRED_PROVIDER_virtual/libgles2 ?= "userland"
-PREFERRED_PROVIDER_virtual/libgl ?= "mesa-gl"
-PREFERRED_PROVIDER_virtual/mesa ?= "mesa-gl"
+PREFERRED_PROVIDER_virtual/egl ?= "${@bb.utils.contains("MACHINE_FEATURES", 
"vc4graphics", "mesa", "userland", d)}"
+PREFERRED_PROVIDER_virtual/libgles2 ?= 
"${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "userland", 
d)}"
+PREFERRED_PROVIDER_virtual/libgl ?= "${@bb.utils.contains("MACHINE_FEATURES", 
"vc4graphics", "mesa", "mesa-gl", d)}"
+PREFERRED_PROVIDER_virtual/mesa ?= "${@bb.utils.contains("MACHINE_FEATURES", 
"vc4graphics", "mesa", "mesa-gl", d)}"
 PREFERRED_PROVIDER_jpeg ?= "jpeg"
-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH v4 03/12] raspberrypi.conf: set the default value of VC4_CMA_SIZE to support vc4graphics

[Herve Jourdain]

Signed-off-by: Herve Jourdain 
---
 conf/machine/raspberrypi.conf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/conf/machine/raspberrypi.conf b/conf/machine/raspberrypi.conf
index 72beeb8..df8194c 100644
--- a/conf/machine/raspberrypi.conf
+++ b/conf/machine/raspberrypi.conf
@@ -10,3 +10,5 @@ include conf/machine/include/rpi-base.inc
 SERIAL_CONSOLE = "115200 ttyAMA0"
 
 UBOOT_MACHINE = "rpi_config"
+VC4_CMA_SIZE_raspberrypi ?= "cma-64"
+
-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH v4 02/12] rpi-base.inc: add vc4-kms-v3d to the overlays to support vc4graphics

[Herve Jourdain]

Signed-off-by: Herve Jourdain 
---
 conf/machine/include/rpi-base.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/conf/machine/include/rpi-base.inc 
b/conf/machine/include/rpi-base.inc
index 47eb23b..aabc131 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -37,6 +37,7 @@ KERNEL_DEVICETREE ?= " \
 overlays/w1-gpio.dtbo \
 overlays/w1-gpio-pullup.dtbo \
 overlays/pi3-miniuart-bt.dtbo \
+overlays/vc4-kms-v3d.dtbo \
 "
 KERNEL_IMAGETYPE ?= "Image"
 
-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH v4 04/12] raspberrypi0.conf: set the default value of VC4_CMA_SIZE to support vc4graphics

[Herve Jourdain]

Signed-off-by: Herve Jourdain 
---
 conf/machine/raspberrypi0.conf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/conf/machine/raspberrypi0.conf b/conf/machine/raspberrypi0.conf
index ccf9ae7..0df9121 100644
--- a/conf/machine/raspberrypi0.conf
+++ b/conf/machine/raspberrypi0.conf
@@ -6,3 +6,5 @@ MACHINEOVERRIDES = "raspberrypi:${MACHINE}"
 include conf/machine/raspberrypi.conf
 
 SERIAL_CONSOLE = "115200 ttyAMA0"
+VC4_CMA_SIZE ?= "cma-128"
+
-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH v4 05/12] raspberrypi2.conf: set the default value of VC4_CMA_SIZE to support vc4graphics

[Herve Jourdain]

Signed-off-by: Herve Jourdain 
---
 conf/machine/raspberrypi2.conf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/conf/machine/raspberrypi2.conf b/conf/machine/raspberrypi2.conf
index d50ef70..3f13dc0 100644
--- a/conf/machine/raspberrypi2.conf
+++ b/conf/machine/raspberrypi2.conf
@@ -10,3 +10,5 @@ include conf/machine/include/rpi-base.inc
 SERIAL_CONSOLE = "115200 ttyAMA0"
 
 UBOOT_MACHINE = "rpi_2_config"
+VC4_CMA_SIZE ?= "cma-256"
+
-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH v4 06/12] raspberrypi3.conf: set the default value of VC4_CMA_SIZE to support vc4graphics

[Herve Jourdain]

Signed-off-by: Herve Jourdain 
---
 conf/machine/raspberrypi3.conf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/conf/machine/raspberrypi3.conf b/conf/machine/raspberrypi3.conf
index cb6056e..438c6e6 100644
--- a/conf/machine/raspberrypi3.conf
+++ b/conf/machine/raspberrypi3.conf
@@ -9,3 +9,5 @@ MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-brcm43430"
 include conf/machine/raspberrypi2.conf
 
 SERIAL_CONSOLE = "115200 ttyS0"
+VC4_CMA_SIZE ?= "cma-256"
+
-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH v4 07/12] rpi-config_git.bb: add v4c overlay to config.txt to support vc4graphics

[Herve Jourdain]

Signed-off-by: Herve Jourdain 
---
 recipes-bsp/bootfiles/rpi-config_git.bb | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb 
b/recipes-bsp/bootfiles/rpi-config_git.bb
index 4bc8eb7..f610718 100644
--- a/recipes-bsp/bootfiles/rpi-config_git.bb
+++ b/recipes-bsp/bootfiles/rpi-config_git.bb
@@ -13,12 +13,14 @@ SRC_URI = 
"git://github.com/Evilpaul/RPi-config.git;protocol=git;branch=master \
 
 S = "${WORKDIR}/git"
 
-PR = "r4"
+PR = "r5"
 
 PITFT="${@bb.utils.contains("MACHINE_FEATURES", "pitft", "1", "0", d)}"
 PITFT22="${@bb.utils.contains("MACHINE_FEATURES", "pitft22", "1", "0", d)}"
 PITFT28r="${@bb.utils.contains("MACHINE_FEATURES", "pitft28r", "1", "0", d)}"
 
+VC4GRAPHICS="${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "1", "0", 
d)}"
+
 inherit deploy
 
 do_deploy() {
@@ -102,6 +104,12 @@ do_deploy() {
 echo "# Enable UART" >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
 echo "enable_uart=1" >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
 fi
+
+# VC4 Graphics support
+if [ "${VC4GRAPHICS}" = "1" ]; then
+echo "# Enable VC4 Graphics" >> 
${DEPLOYDIR}/bcm2835-bootfiles/config.txt
+echo "dtoverlay=vc4-kms-v3d,${VC4_CMA_SIZE}" >> 
${DEPLOYDIR}/bcm2835-bootfiles/config.txt
+fi
 }
 
 addtask deploy before do_package after do_install
-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH v4 08/12] wayland/weston_%.bbappend: modify configuration options to support vc4graphics

[Herve Jourdain]

Signed-off-by: Herve Jourdain 
---
 recipes-graphics/wayland/weston_%.bbappend | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/recipes-graphics/wayland/weston_%.bbappend 
b/recipes-graphics/wayland/weston_%.bbappend
index c3a7421..57b8079 100644
--- a/recipes-graphics/wayland/weston_%.bbappend
+++ b/recipes-graphics/wayland/weston_%.bbappend
@@ -1,4 +1,2 @@
-EXTRA_OECONF_append_rpi = "\
---enable-rpi-compositor \
-WESTON_NATIVE_BACKEND=rpi-backend.so \
-   "
+EXTRA_OECONF_append_rpi = "${@bb.utils.contains('MACHINE_FEATURES', 
'vc4graphics', '', ' --enable-rpi-compositor 
WESTON_NATIVE_BACKEND=rpi-backend.so', d)}"
+
-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH v4 09/12] weston/weston_%.bbappend: modify configuration options to support vc4graphics

[Herve Jourdain]

Signed-off-by: Herve Jourdain 
---
 recipes-graphics/weston/weston_%.bbappend | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/recipes-graphics/weston/weston_%.bbappend 
b/recipes-graphics/weston/weston_%.bbappend
index 3ec311d..70f4360 100644
--- a/recipes-graphics/weston/weston_%.bbappend
+++ b/recipes-graphics/weston/weston_%.bbappend
@@ -1,7 +1,8 @@
-EXTRA_OECONF += "--enable-rpi-compositor \
- --disable-resize-optimization \
- --disable-setuid-install \
- --disable-xwayland-test \
- --disable-simple-egl-clients \
- WESTON_NATIVE_BACKEND=rpi-backend.so \
+PACKAGECONFIG_rpi_remove = "${@bb.utils.contains('MACHINE_FEATURES', 
'vc4graphics', ' fbdev', '', d)}"
+EXTRA_OECONF += "--disable-xwayland-test \
+ --disable-simple-egl-clients \
 "
+EXTRA_OECONF += "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', 
'--enable-rpi-compositor', d)}"
+EXTRA_OECONF += "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', 
'--disable-resize-optimization', d)}"
+EXTRA_OECONF += "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', 
'--disable-setuid-install', d)}"
+EXTRA_OECONF += "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', 
'WESTON_NATIVE_BACKEND=rpi-backend.so', d)}"
-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH v4 10/12] mesa_%.bbappend: new file to add the correct configuration options to support vc4graphics

[Herve Jourdain]

Signed-off-by: Herve Jourdain 
---
 recipes-graphics/mesa/mesa_%.bbappend | 4 
 1 file changed, 4 insertions(+)
 create mode 100644 recipes-graphics/mesa/mesa_%.bbappend

diff --git a/recipes-graphics/mesa/mesa_%.bbappend 
b/recipes-graphics/mesa/mesa_%.bbappend
new file mode 100644
index 000..b182388
--- /dev/null
+++ b/recipes-graphics/mesa/mesa_%.bbappend
@@ -0,0 +1,4 @@
+PACKAGECONFIG_append_rpi = " gallium"
+GALLIUMDRIVERS_rpi = "vc4"
+DRIDRIVERS_rpi = ""
+
-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH v4 11/12] linux-rpi.inc: add the configuration options required to support vc4graphics

[Herve Jourdain]

Signed-off-by: Herve Jourdain 
---
 recipes-kernel/linux/linux-rpi.inc | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/recipes-kernel/linux/linux-rpi.inc 
b/recipes-kernel/linux/linux-rpi.inc
index 4b65fc2..3eeefee 100644
--- a/recipes-kernel/linux/linux-rpi.inc
+++ b/recipes-kernel/linux/linux-rpi.inc
@@ -111,6 +111,16 @@ do_configure_prepend() {
 # Activate CONFIG_LEGACY_PTYS
 kernel_configure_variable LEGACY_PTYS y
 
+# Activate the configuration options for VC4
+VC4GRAPHICS="${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "1", 
"0", d)}"
+if [ ${VC4GRAPHICS} = "1" ]; then
+kernel_configure_variable I2C_BCM2835 y
+kernel_configure_variable DRM y
+kernel_configure_variable DRM_FBDEV_EMULATION n
+kernel_configure_variable DRM_VC4 y
+kernel_configure_variable FB_BCM2708 n
+fi
+
 # Keep this the last line
 # Remove all modified configs and add the rest to .config
 sed -e "${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config'
-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH v4 12/12] linux-raspberrypi-4.4: add patch to enable proper operation of renderD128 device

[Herve Jourdain]

Signed-off-by: Herve Jourdain 
---
 .../0002-vc4-ioctl-rendering-allow.patch   | 29 ++
 recipes-kernel/linux/linux-raspberrypi_4.4.bb  |  1 +
 2 files changed, 30 insertions(+)
 create mode 100644 
recipes-kernel/linux/linux-raspberrypi-4.4/0002-vc4-ioctl-rendering-allow.patch

diff --git 
a/recipes-kernel/linux/linux-raspberrypi-4.4/0002-vc4-ioctl-rendering-allow.patch
 
b/recipes-kernel/linux/linux-raspberrypi-4.4/0002-vc4-ioctl-rendering-allow.patch
new file mode 100644
index 000..59d0ed7
--- /dev/null
+++ 
b/recipes-kernel/linux/linux-raspberrypi-4.4/0002-vc4-ioctl-rendering-allow.patch
@@ -0,0 +1,29 @@
+This patch has been accepted upstream in kernel 4.7-rc3
+But it has not yet been backported to 4.4...
+Upstream-Status: Accepted 
[http://www.gossamer-threads.com/lists/linux/kernel/2459302]
+Signed-off-by: Herve Jourdain 
+---
+
+diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
+index a5b68c1..14b5ec1 100644
+--- a/drivers/gpu/drm/vc4/vc4_drv.c
 b/drivers/gpu/drm/vc4/vc4_drv.c
+@@ -75,12 +75,12 @@ static const struct file_operations vc4_drm_fops = {
+ };
+ 
+ static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
+-  DRM_IOCTL_DEF_DRV(VC4_SUBMIT_CL, vc4_submit_cl_ioctl, 0),
+-  DRM_IOCTL_DEF_DRV(VC4_WAIT_SEQNO, vc4_wait_seqno_ioctl, 0),
+-  DRM_IOCTL_DEF_DRV(VC4_WAIT_BO, vc4_wait_bo_ioctl, 0),
+-  DRM_IOCTL_DEF_DRV(VC4_CREATE_BO, vc4_create_bo_ioctl, 0),
+-  DRM_IOCTL_DEF_DRV(VC4_MMAP_BO, vc4_mmap_bo_ioctl, 0),
+-  DRM_IOCTL_DEF_DRV(VC4_CREATE_SHADER_BO, vc4_create_shader_bo_ioctl, 0),
++  DRM_IOCTL_DEF_DRV(VC4_SUBMIT_CL, vc4_submit_cl_ioctl, 
0|DRM_RENDER_ALLOW),
++  DRM_IOCTL_DEF_DRV(VC4_WAIT_SEQNO, vc4_wait_seqno_ioctl, 
0|DRM_RENDER_ALLOW),
++  DRM_IOCTL_DEF_DRV(VC4_WAIT_BO, vc4_wait_bo_ioctl, 0|DRM_RENDER_ALLOW),
++  DRM_IOCTL_DEF_DRV(VC4_CREATE_BO, vc4_create_bo_ioctl, 
0|DRM_RENDER_ALLOW),
++  DRM_IOCTL_DEF_DRV(VC4_MMAP_BO, vc4_mmap_bo_ioctl, 0|DRM_RENDER_ALLOW),
++  DRM_IOCTL_DEF_DRV(VC4_CREATE_SHADER_BO, vc4_create_shader_bo_ioctl, 
0|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(VC4_GET_HANG_STATE, vc4_get_hang_state_ioctl,
+ DRM_ROOT_ONLY),
+ };
diff --git a/recipes-kernel/linux/linux-raspberrypi_4.4.bb 
b/recipes-kernel/linux/linux-raspberrypi_4.4.bb
index b13925c..8fe5330 100644
--- a/recipes-kernel/linux/linux-raspberrypi_4.4.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_4.4.bb
@@ -5,5 +5,6 @@ LINUX_VERSION ?= "4.4.13"
 SRCREV = "680be5e27a9593cf26079c6e5744a04cc2809d13"
 SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.4.y \
file://0001-fix-dtbo-rules.patch \
+   file://0002-vc4-ioctl-rendering-allow.patch \
 "
 require linux-raspberrypi.inc
-- 
2.7.4

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

Re: [yocto] kernel menuconfig/ncurses patch in linux-yocto

[Bruce Ashfield]

On 2016-07-21 02:35 AM, Jacob Kroon wrote:

On Thu, Jul 21, 2016 at 5:22 AM, Bruce Ashfield
 wrote:

On 2016-07-20 4:19 PM, Jacob Kroon wrote:


Hi,
I'm trying to get the SDK to be able to run the kernel's "make
menuconfig" target
using nativesdk-ncurses from the SDK. Looking at


http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.4/commit/scripts/kconfig/lxdialog/check-lxdialog.sh?h=standard/beaglebone&id=badf6fedf455958fe0ff3c060c8e3965ef6d80dc

I figured out I could pass CROSS_CURSES_[INC,LIB], but the second chunk
in that patch looks weird:

 elif pkg-config --cflags ncurses 2>/dev/null; then
 echo '-DCURSES_LOC=""'
+   if [ x"$CROSS_CURSES_INC" != x ]; then
+   echo "$CROSS_CURSES_INC"
+   exit
+   fi
 elif [ -f /usr/include/ncursesw/curses.h ]; then
 echo '-I/usr/include/ncursesw -DCURSES_LOC=""'

(I had to do manual indentation with spaces in gmail)
Is the indentation or the logic incorrect ?



In the commit itself, the indentation is fine.

That block of code is just dumping flags that are used in the
build. So in this case, it is correct. If the variable is
non empty, it is echoed and then processing exits.


The check if CROSS_CURSES_INC is non-empty is only done if the preceeding
  "elif"-check is true, and not unconditionally as one would expect
judging by the indentation.


Yep, that's the point. It goes to pkgconfig first, and then falls
back to that.

The indention is fine in the actual repository.

--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -4,6 +4,10 @@
 # What library to link
 ldflags()
 {
+   if [ "$CROSS_CURSES_LIB" != "" ]; then
+   echo "$CROSS_CURSES_LIB"
+   exit
+   fi
pkg-config --libs ncursesw 2>/dev/null && exit
pkg-config --libs ncurses 2>/dev/null && exit
for ext in so a dll.a dylib ; do
@@ -25,6 +29,10 @@ ccflags()
echo '-DCURSES_LOC="" -DNCURSES_WIDECHAR=1'
elif pkg-config --cflags ncurses 2>/dev/null; then
echo '-DCURSES_LOC=""'
+   if [ x"$CROSS_CURSES_INC" != x ]; then
+   echo "$CROSS_CURSES_INC"
+   exit
+   fi
elif [ -f /usr/include/ncursesw/curses.h ]; then
echo '-I/usr/include/ncursesw -DCURSES_LOC=""'
echo ' -DNCURSES_WIDECHAR=1'



Bruce





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

Re: [yocto] kernel menuconfig/ncurses patch in linux-yocto

[Bruce Ashfield]

On 2016-07-21 08:58 AM, Bruce Ashfield wrote:

On 2016-07-21 02:35 AM, Jacob Kroon wrote:

On Thu, Jul 21, 2016 at 5:22 AM, Bruce Ashfield
 wrote:

On 2016-07-20 4:19 PM, Jacob Kroon wrote:


Hi,
I'm trying to get the SDK to be able to run the kernel's "make
menuconfig" target
using nativesdk-ncurses from the SDK. Looking at


http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.4/commit/scripts/kconfig/lxdialog/check-lxdialog.sh?h=standard/beaglebone&id=badf6fedf455958fe0ff3c060c8e3965ef6d80dc


I figured out I could pass CROSS_CURSES_[INC,LIB], but the second chunk
in that patch looks weird:

 elif pkg-config --cflags ncurses 2>/dev/null; then
 echo '-DCURSES_LOC=""'
+   if [ x"$CROSS_CURSES_INC" != x ]; then
+   echo "$CROSS_CURSES_INC"
+   exit
+   fi
 elif [ -f /usr/include/ncursesw/curses.h ]; then
 echo '-I/usr/include/ncursesw -DCURSES_LOC=""'

(I had to do manual indentation with spaces in gmail)
Is the indentation or the logic incorrect ?



In the commit itself, the indentation is fine.

That block of code is just dumping flags that are used in the
build. So in this case, it is correct. If the variable is
non empty, it is echoed and then processing exits.


The check if CROSS_CURSES_INC is non-empty is only done if the preceeding
  "elif"-check is true, and not unconditionally as one would expect
judging by the indentation.


Yep, that's the point. It goes to pkgconfig first, and then falls
back to that.

The indention is fine in the actual repository.


oh wait.

I had my coffee and I see now what you mean, I was checking
older repos, and when this merged into the 4.4 tree it does
look like the conditional is hosed.

I'll queue up a closer look at this later today.

Bruce



--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -4,6 +4,10 @@
  # What library to link
  ldflags()
  {
+   if [ "$CROSS_CURSES_LIB" != "" ]; then
+   echo "$CROSS_CURSES_LIB"
+   exit
+   fi
 pkg-config --libs ncursesw 2>/dev/null && exit
 pkg-config --libs ncurses 2>/dev/null && exit
 for ext in so a dll.a dylib ; do
@@ -25,6 +29,10 @@ ccflags()
 echo '-DCURSES_LOC="" -DNCURSES_WIDECHAR=1'
 elif pkg-config --cflags ncurses 2>/dev/null; then
 echo '-DCURSES_LOC=""'
+   if [ x"$CROSS_CURSES_INC" != x ]; then
+   echo "$CROSS_CURSES_INC"
+   exit
+   fi
 elif [ -f /usr/include/ncursesw/curses.h ]; then
 echo '-I/usr/include/ncursesw -DCURSES_LOC=""'
 echo ' -DNCURSES_WIDECHAR=1'



Bruce







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

Re: [yocto] [genericx86-jethro] core-image-sato HDDIMG 'install' - no hard drive selected - /etc/fstab no such file or directory

[Khem Raj]

On Thu, Jul 21, 2016 at 2:15 AM, Simon Bolek  wrote:
> Hi Raj,
> Thank you.
> I have already tried this.
>
> I managed to start the USB installation by addding
> kernel-modules
> to core-image-minimal-initramfs.bb
>
> However after the installation, system will not boot up due to kernel panic:
> VFS: Cannot open root device "sda2" or unknown block (0,0) Please append a
> correct "root=" boot option;

can you add

SYSLINUX_ROOT = "root=/dev/hda2"

to local.conf and rebuild ?

>
> It seems, the SDD hard drive is found on installation time, but not on boot
> time.
> How is that possible? It did work with FIDO, but is not working with JETHRO.
> Any hint what I have to look for now? Is it the drivers missing? Or maybe
> some scripts not running at boot?
> What will run at boot prior to mounting what is stated in root= in grub.cfg?
>
> kind regards
> Simon :-)
>
>
> On Sat, Jul 16, 2016 at 2:02 AM, Khem Raj  wrote:
>>
>> On Fri, Jul 15, 2016 at 3:17 PM, Simon Bolek 
>> wrote:
>> > Hi Raj,
>> >
>> > Maybe you could help me with this.
>> > I found out that during rootfs (meta/lib/oe/rootfs.py), depmodwrapper
>> > script
>> > is beeing called.
>> > I noticed, that it does generate /lib/modules/.. directory
>> > structure
>> > under:
>> > poky/build/tmp/work/genericx86-poky-linux/core-image-sato
>> > However, at the end of the bitbake process, there is no /lib/modules
>> > direcotry in
>> > core-image-minimal-initramfs-genericx86-20160715210400.rootfs.cpio.gz
>> >
>> > Where are the steps, where this .cpio.gz file is beeing generated. There
>> > must be a place where all the files, that are inside, are beeing put
>> > together.
>>
>> initramfs image is a separate image. What you are seeing is the final
>> image.
>> you might have to add the kernel module to you machine conf
>>
>> MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
>>
>> >
>> > HELP!
>> > kind regards
>> > Simon :-)
>> >
>> >
>> >
>> > On Fri, Jul 15, 2016 at 10:59 AM, Simon Bolek
>> > 
>> > wrote:
>> >>
>> >> Thanks, but neither:
>> >> pkg_postinst_kernel-base ()
>> >> nor:
>> >> pkg_postinst_kernel-image ()
>> >> from /meta/classes/kernel.bbclass gets called when running:
>> >> - bitbake core-image-sato or
>> >> - bitbake linux-yocto
>> >>
>> >> I put some commands in there, which are definitely wrong (like foobar)
>> >> and
>> >> bitbake run successfully.
>> >> Whereas, in other funtions it caused problems.
>> >> Any ideas how can fix this?
>> >>
>> >> thanks and best regards
>> >> Simon :-)
>> >>
>> >>
>> >> On Fri, Jul 15, 2016 at 1:30 AM, Khem Raj  wrote:
>> >>>
>> >>> On Thu, Jul 14, 2016 at 4:16 PM, Simon Bolek
>> >>> 
>> >>> wrote:
>> >>> > Hi Raj,
>> >>> >
>> >>> > About depmod again.
>> >>> > Should it be run from meta/classes/kernel.bbclass  ?
>> >>> > ...
>> >>> > pkg_postinst_kernel-base () {
>> >>> > if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
>> >>> > mkdir -p $D/lib/modules/${KERNEL_VERSION}
>> >>> > fi
>> >>> > if [ -n "$D" ]; then
>> >>> > depmodwrapper -a -b $D ${KERNEL_VERSION}
>> >>> > else
>> >>> > depmod -a ${KERNEL_VERSION}
>> >>> > fi
>> >>> > }
>> >>> > ...
>> >>> >
>> >>> > Where is this function beeing called?
>> >>>
>> >>> It should be called during rootfs and image creation time. as well as
>> >>> when you update the package using online package manager.
>> >>>
>> >>> > I did not find it anywhere.
>> >>> > thanks and kind regards
>> >>> > Simon :-)
>> >>> >
>> >>> > On Thu, Jul 14, 2016 at 8:32 AM, Simon Bolek
>> >>> > 
>> >>> > wrote:
>> >>> >>
>> >>> >>
>> >>> >> On Wed, Jul 13, 2016 at 4:56 PM, Khem Raj 
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> On Wed, Jul 13, 2016 at 4:57 AM, Simon Bolek
>> >>> >>> 
>> >>> >>> wrote:
>> >>> >>> > Hi Raj,
>> >>> >>> >
>> >>> >>> > So i tried to do manually, what init script does and udev
>> >>> >>> > definitely
>> >>> >>> > does
>> >>> >>> > not recognize the SSD drive.
>> >>> >>> > I ran
>> >>> >>> >  /lib/udev/udevd --daemon --debug > udev.debug 2>&1 &
>> >>> >>> > from the cli and there is no trace of recognizing the SSD. Only
>> >>> >>> > the
>> >>> >>> > /dev/sda, which is the USB stick I am running the installation
>> >>> >>> > from.
>> >>> >>> >
>> >>> >>> > I used 'meld' to compare the /initrd from current jethro image
>> >>> >>> > and
>> >>> >>> > previous
>> >>> >>> > working fido image.
>> >>> >>> > They are almost the same:
>> >>> >>> > - in jethro /lib/modules... file structure is missing with:
>> >>> >>> > modules.alias
>> >>> >>> > modules.alias.bin
>> >>> >>> > modules.builtin.bin
>> >>> >>> > modules.dep
>> >>> >>> > modules.dep.bin
>> >>> >>> > modules.devname
>> >>> >>> > modules.softdep
>> >>> >>> > modules.symbols
>> >>> >>> > modules.symbols.bin
>> >>> >>>
>> >>> >>> this means depmod did not run during initramfs image creation
>> >>> >>
>> >>> >> How can I make this happen during bitbake, so i have those files in
>> >>> >> the
>> >>> >> HDDIMG?
>> >>> >>
>> >>> >>>
>> >>> >>> >
>> >>> >>> > - there are slight differe

Re: [yocto] [meta-security][PATCH] Fix a trousers build on when not in use systemd: unparsed line: 'inherit'

[Khem Raj]

On Thu, Jul 21, 2016 at 1:48 AM, Thomas Perrot  wrote:
> Signed-off-by: Thomas Perrot 
> ---
>  recipes-tpm/trousers/trousers_0.3.13.bb | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/recipes-tpm/trousers/trousers_0.3.13.bb 
> b/recipes-tpm/trousers/trousers_0.3.13.bb
> index e274972..6853f18 100644
> --- a/recipes-tpm/trousers/trousers_0.3.13.bb
> +++ b/recipes-tpm/trousers/trousers_0.3.13.bb
> @@ -16,8 +16,7 @@ SRC_URI = 
> "http://sourceforge.net/projects/trousers/files/${BPN}/${PV}/${BPN}-${
>  SRC_URI[md5sum] = "ad508f97b406f6e48cd90e85d78e7ca8"
>  SRC_URI[sha256sum] = 
> "bb908e4a3c88a17b247a4fc8e0fff3419d8a13170fe7bdfbe0e2c5c082a276d3"
>
> -inherit autotools pkgconfig useradd update-rc.d
> -inherit 
> ${@bb.utils.contains('VIRTUAL-RUNTIME_init_manager','systemd','systemd','', 
> d)}
> +inherit autotools pkgconfig useradd update-rc.d 
> ${@bb.utils.contains('VIRTUAL-RUNTIME_init_manager','systemd','systemd','', 
> d)}

while this is ok. For consistency may be check for systemd in
DISTRO_FEATURES check is better since thats what is used in other
places.

>
>  PACKAGECONFIG ?= "gmp "
>  PACKAGECONFIG[gmp] = "--with-gmp, --with-gmp=no, gmp"
> --
> 2.1.4
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Is it possible to install *.deb file directly in the yocto platform?

[Khem Raj]

On Thu, Jul 21, 2016 at 1:52 AM, 윤영석  wrote:

> hi,
>
>
>
> i just want to install some deb file, Is it possible?
>

​if the image has dpkg/apt installed, you _may_ be able to install
however, keep in mind it does not hook into debian/ubuntu feeds for .deb
packages
but if you have generated feeds using yocto then certainly it will work.​



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

Re: [yocto] populate_sdk and external toolchain

[Khem Raj]

On Thu, Jul 21, 2016 at 2:18 AM, Manish Jaggi  wrote:
> I am trying to build sdk (using populate_sdk option).
> Toolchain being used is an external one.
>
> When I run bitbake core-image-minimal -c populate_sdk, I get the below error
>
> | checking for x86_64-pokysdk-linux-gcc...  
> /home/manish/poky/build/tmp/work/x86_64-linux/gcc-crosssdk-initial-x86_64/5.2.0-r0/gcc-5.2.0/build.x86_64-linux.x86_64-pokysdk-linux/./gcc/xgcc
> -B/home/manish/poky/build/tmp/work/x86_64-linux/gcc-crosssdk-initial-x86_64/5.2.0-r0/gcc-5.2.0/build.x86_64-linux.x86_64-pokysdk-linux/./gcc/
> -B/home/manish/poky/build/tmp/sysroots/x86_64-linux/usr/x86_64-pokysdk-linux/bin/
>  
> -B/home/manish/poky/build/tmp/sysroots/x86_64-linux/usr/x86_64-pokysdk-linux/lib/
>  -isystem
> /home/manish/poky/build/tmp/sysroots/x86_64-linux/usr/x86_64-pokysdk-linux/include
>  -isystem 
> /home/manish/poky/build/tmp/sysroots/x86_64-linux/usr/x86_64-pokysdk-linux/sys-include
> --sysroot=/home/manish/poky/build/tmp/work/x86_64-linux/gcc-crosssdk-initial-x86_64/5.2.0-r0/gcc-5.2.0/build.x86_64-linux.x86_64-pokysdk-linux/tmpsysroot
> | checking for suffix of object files... configure: error: in
> `/home/manish/poky/build/tmp/work/x86_64-linux/gcc-crosssdk-initial-x86_64/5.2.0-r0/gcc-5.2.0/build.x86_64-linux.x86_64-pokysdk-linux/x86_64-pokysdk-linux/libgcc':
> | configure: error: cannot compute suffix of object files: cannot compile

there should be a config.log file in build directory of libgcc which
should have more details as to why compiler failed

>
> Is it possible to remove gcc-crosssdk from populate_sdk script ?
>
>
>
> --
> ___
> 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] U-boot tool/mkimage Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined)

[Bill zhang]

Hi all,

I want to use U-boot tool "mkimage" to sign images with RSA keys for secure
boot, but the mkimage built from YOCTO v1.7 does not support options:
-k,-K,

when run command:
${mkimage} -D "${dtc}" -F -k dev-keys -K sandbox-u-boot.dtb \
-r test.fit >${tmp},

it failed, with usage() printed out:

mkimage -l
Usage: ./mkimage -l image
  -l ==> list image header information
   ./mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name
-d data_file[:data_file...] image
  -A ==> set architecture to 'arch'
  -O ==> set operating system to 'os'
  -T ==> set image type to 'type'
  -C ==> set compression type 'comp'
  -a ==> set load address to 'addr' (hex)
  -e ==> set entry point to 'ep' (hex)
  -n ==> set image name to 'name'
  -d ==> use image data from 'datafile'
  -x ==> set XIP (execute in place)
   ./mkimage [-D dtc_options] [-f fit-image.its|-F] fit-image
  -D => set options for device tree compiler
  -f => input filename for FIT source
Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined)
   ./mkimage -V ==> print version information and exit

How to build tools "mkimage" with  "signing/verifying enabled" ?

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

[yocto] 'recipetool newappend' usage

[Sai Pavan Boddu]

Hi there,

I am using recipetool for creating bbappend files for few existing recipes. I 
am not finding a good way get the bbappend file path from a layer.

But I observer that, when I use "recipetool newappend" specifying recipes which 
are already has bbappends in a layer, I'm not warned or shown an error. Instead 
it always returns the full bbappend path.

Ex:

Run the below command twice, even though file exists already after trial1, it 
doesn't error out, And even doesn't overwrite

recipetool newappend meta-something linux-xlnx

So shall I take this as a feature, to find-out the bbappend paths in the layer 
? or its there any good way ?

Regards,

B. Sai pavan


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

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

Re: [yocto] kernel menuconfig/ncurses patch in linux-yocto

[Jacob Kroon]

On Thu, Jul 21, 2016 at 3:06 PM, Bruce Ashfield
 wrote:
> On 2016-07-21 08:58 AM, Bruce Ashfield wrote:
>>
>> On 2016-07-21 02:35 AM, Jacob Kroon wrote:
>>>
>>> On Thu, Jul 21, 2016 at 5:22 AM, Bruce Ashfield
>>>  wrote:

 On 2016-07-20 4:19 PM, Jacob Kroon wrote:
>
>
> Hi,
> I'm trying to get the SDK to be able to run the kernel's "make
> menuconfig" target
> using nativesdk-ncurses from the SDK. Looking at
>
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.4/commit/scripts/kconfig/lxdialog/check-lxdialog.sh?h=standard/beaglebone&id=badf6fedf455958fe0ff3c060c8e3965ef6d80dc
>
>
> I figured out I could pass CROSS_CURSES_[INC,LIB], but the second chunk
> in that patch looks weird:
>
>  elif pkg-config --cflags ncurses 2>/dev/null; then
>  echo '-DCURSES_LOC=""'
> +   if [ x"$CROSS_CURSES_INC" != x ]; then
> +   echo "$CROSS_CURSES_INC"
> +   exit
> +   fi
>  elif [ -f /usr/include/ncursesw/curses.h ]; then
>  echo '-I/usr/include/ncursesw -DCURSES_LOC=""'
>
> (I had to do manual indentation with spaces in gmail)
> Is the indentation or the logic incorrect ?



 In the commit itself, the indentation is fine.

 That block of code is just dumping flags that are used in the
 build. So in this case, it is correct. If the variable is
 non empty, it is echoed and then processing exits.
>>>
>>>
>>> The check if CROSS_CURSES_INC is non-empty is only done if the preceeding
>>>   "elif"-check is true, and not unconditionally as one would expect
>>> judging by the indentation.
>>
>>
>> Yep, that's the point. It goes to pkgconfig first, and then falls
>> back to that.
>>
>> The indention is fine in the actual repository.
>
>
> oh wait.
>
> I had my coffee and I see now what you mean, I was checking
> older repos, and when this merged into the 4.4 tree it does
> look like the conditional is hosed.
>
> I'll queue up a closer look at this later today.
>
> Bruce
>

Ah, that explains it. Thank you for looking into it.

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

[yocto] [meta-raspberrypi] linux-raspberrypi versions

[Paul Barker]

Hi all,

I'm planning to look at the linux-raspberypi recipes once I've had time
to send V2 of my u-boot patches. I'd like to know people's thoughts on
the available kernel versions in the meta-raspberrypi layer:

Is anyone still using the linux-raspberrypi 3.18 recipe? The commit
referenced in SRCREV is from June 2015. I think it's probably time to
retire this unless anyone has a reason to keep it around.

Is there any reason to keep linux-raspberrypi 4.1 as the default
recipe? The last commit to the 4.1 branch was in April and the
default branch on the linux-raspberrypi GitHub repository has been
4.4 since then. I think we should change the default version to 4.4
unless there's a good reason not to.

If there's no objections I'll send a couple of patches to drop 3.18 and
change the default to 4.4.

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

Re: [yocto] [meta-raspberrypi] linux-raspberrypi versions

[Herve Jourdain]

Hi Paul,

I had the same line of thoughts...
I believe 3.18 should be dropped, maybe even 4.1, default to 4.4, and maybe
add 4.7 to the mix, since 4.7 seems to be where the bulk of the work is done
now.

Herve

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Paul Barker
Sent: jeudi 21 juillet 2016 09:03
To: yocto@yoctoproject.org
Subject: [yocto] [meta-raspberrypi] linux-raspberrypi versions

Hi all,

I'm planning to look at the linux-raspberypi recipes once I've had time to
send V2 of my u-boot patches. I'd like to know people's thoughts on the
available kernel versions in the meta-raspberrypi layer:

Is anyone still using the linux-raspberrypi 3.18 recipe? The commit
referenced in SRCREV is from June 2015. I think it's probably time to retire
this unless anyone has a reason to keep it around.

Is there any reason to keep linux-raspberrypi 4.1 as the default recipe? The
last commit to the 4.1 branch was in April and the default branch on the
linux-raspberrypi GitHub repository has been
4.4 since then. I think we should change the default version to 4.4 unless
there's a good reason not to.

If there's no objections I'll send a couple of patches to drop 3.18 and
change the default to 4.4.

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

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

Re: [yocto] kernel menuconfig/ncurses patch in linux-yocto

[Bruce Ashfield]

On 2016-07-21 10:24 AM, Jacob Kroon wrote:

On Thu, Jul 21, 2016 at 3:06 PM, Bruce Ashfield
 wrote:

On 2016-07-21 08:58 AM, Bruce Ashfield wrote:


On 2016-07-21 02:35 AM, Jacob Kroon wrote:


On Thu, Jul 21, 2016 at 5:22 AM, Bruce Ashfield
 wrote:


On 2016-07-20 4:19 PM, Jacob Kroon wrote:



Hi,
I'm trying to get the SDK to be able to run the kernel's "make
menuconfig" target
using nativesdk-ncurses from the SDK. Looking at



http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.4/commit/scripts/kconfig/lxdialog/check-lxdialog.sh?h=standard/beaglebone&id=badf6fedf455958fe0ff3c060c8e3965ef6d80dc


I figured out I could pass CROSS_CURSES_[INC,LIB], but the second chunk
in that patch looks weird:

  elif pkg-config --cflags ncurses 2>/dev/null; then
  echo '-DCURSES_LOC=""'
+   if [ x"$CROSS_CURSES_INC" != x ]; then
+   echo "$CROSS_CURSES_INC"
+   exit
+   fi
  elif [ -f /usr/include/ncursesw/curses.h ]; then
  echo '-I/usr/include/ncursesw -DCURSES_LOC=""'

(I had to do manual indentation with spaces in gmail)
Is the indentation or the logic incorrect ?




In the commit itself, the indentation is fine.

That block of code is just dumping flags that are used in the
build. So in this case, it is correct. If the variable is
non empty, it is echoed and then processing exits.



The check if CROSS_CURSES_INC is non-empty is only done if the preceeding
   "elif"-check is true, and not unconditionally as one would expect
judging by the indentation.



Yep, that's the point. It goes to pkgconfig first, and then falls
back to that.

The indention is fine in the actual repository.



oh wait.

I had my coffee and I see now what you mean, I was checking
older repos, and when this merged into the 4.4 tree it does
look like the conditional is hosed.

I'll queue up a closer look at this later today.

Bruce



Ah, that explains it. Thank you for looking into it.


Yup. The original patch (of 3.14 vintage) had migrated that chunk over
time to an invalid location.

I fixed the block in the 4.4 kernel, and have refreshed the path so
it will be fixed for the next linux-yocto kernel as well.

I've pushed the changes to the tree, and will follow up with SRCREV
bumps when my next change queue is ready.

Bruce



Jacob



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

Re: [yocto] Error during adding a new recipe.

[Burton, Ross]

On 21 July 2016 at 22:51, Vijayakumar Badiger 
wrote:

> /local/mnt/workspace/c_vbadig/LV/poky/build/tmp-glibc/work/aarch64-poky-linux/system-core/git-r17/system/core/libsync/sync.c:24:24:
> fatal error: linux/sync.h: No such file or directory
> compilation terminated.
> make[2]: *** [libsync_la-sync.lo] Error 1
>

That's not a standard user-space kernel header and doesn't appear to be a
standard header at all, so the question is where do you expect that header
to come from?

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

[yocto] Error during adding a new recipe.

[Vijayakumar Badiger]

Hello all,

I am facing error while integrating a new recipe in to my Yacto project.


/local/mnt/workspace/c_vbadig/LV/poky/build/tmp-glibc/work/aarch64-poky-linux/system-core/git-r17/system/core/libsync/sync.c:24:24:
fatal error: linux/sync.h: No such file or directory
compilation terminated.
make[2]: *** [libsync_la-sync.lo] Error 1

Not sure why its complaining about this missing header file. I am trying to
integrate the system/core in to the Yacto baseline . Please can some one
help as I am blocked because of this. Thanks.

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

Re: [yocto] Error during adding a new recipe.

[Khem Raj]

> On Jul 21, 2016, at 2:59 PM, Burton, Ross  wrote:
> 
> 
> On 21 July 2016 at 22:51, Vijayakumar Badiger  > wrote:
> /local/mnt/workspace/c_vbadig/LV/poky/build/tmp-glibc/work/aarch64-poky-linux/system-core/git-r17/system/core/libsync/sync.c:24:24:
>  fatal error: linux/sync.h: No such file or directory
> compilation terminated.
> make[2]: *** [libsync_la-sync.lo] Error 1
> 
> That's not a standard user-space kernel header and doesn't appear to be a 
> standard header at all, so the question is where do you expect that header to 
> come from?
> 

Its from android sync driver for kernel, which is not upstreamed yet.

> Ross
> --
> ___
> 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] Error during adding a new recipe.

[Vijayakumar Badiger]

I am trying to integrate the adb daemon by pulling in the userspace project
from the android system/core.
http://androidxref.com/6.0.1_r10/xref/system/core/
When we try to compile libsync I am getting this error. Can you pls let me
know how to overcome this. Thanks.



On Thu, Jul 21, 2016 at 3:08 PM, Khem Raj  wrote:

>
> On Jul 21, 2016, at 2:59 PM, Burton, Ross  wrote:
>
>
> On 21 July 2016 at 22:51, Vijayakumar Badiger 
> wrote:
>
>> /local/mnt/workspace/c_vbadig/LV/poky/build/tmp-glibc/work/aarch64-poky-linux/system-core/git-r17/system/core/libsync/sync.c:24:24:
>> fatal error: linux/sync.h: No such file or directory
>> compilation terminated.
>> make[2]: *** [libsync_la-sync.lo] Error 1
>>
>
> That's not a standard user-space kernel header and doesn't appear to be a
> standard header at all, so the question is where do you expect that header
> to come from?
>
>
> Its from android sync driver for kernel, which is not upstreamed yet.
>
> Ross
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error during adding a new recipe.

[Khem Raj]

> On Jul 21, 2016, at 3:34 PM, Vijayakumar Badiger  
> wrote:
> 
> I am trying to integrate the adb daemon by pulling in the userspace project 
> from the android system/core. 
> http://androidxref.com/6.0.1_r10/xref/system/core/ 
> 
> When we try to compile libsync I am getting this error. Can you pls let me 
> know how to overcome this. Thanks.
> 
> 

you need to port the sync driver to kernel you are using and also it should be 
patching the kernel-headers package since it seems they are also exposing
some APIs to userspace.

> 
> On Thu, Jul 21, 2016 at 3:08 PM, Khem Raj  > wrote:
> 
>> On Jul 21, 2016, at 2:59 PM, Burton, Ross > > wrote:
>> 
>> 
>> On 21 July 2016 at 22:51, Vijayakumar Badiger > > wrote:
>> /local/mnt/workspace/c_vbadig/LV/poky/build/tmp-glibc/work/aarch64-poky-linux/system-core/git-r17/system/core/libsync/sync.c:24:24:
>>  fatal error: linux/sync.h: No such file or directory
>> compilation terminated.
>> make[2]: *** [libsync_la-sync.lo] Error 1
>> 
>> That's not a standard user-space kernel header and doesn't appear to be a 
>> standard header at all, so the question is where do you expect that header 
>> to come from?
>> 
> 
> Its from android sync driver for kernel, which is not upstreamed yet.
> 
>> Ross
>> --
>> ___
>> 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] Error during adding a new recipe.

[Vijayakumar Badiger]

The sync driver is already ported in the kernel.  I just need to get this
compilation error fixed. I tried adding below change to kernel bb file but
still I get that same error.

PACKAGES =+ "kernel-headers"
FILES_kernel-headers = "${KDIR}/usr/include"


Cheers
Vijay


On Thu, Jul 21, 2016 at 4:11 PM, Khem Raj  wrote:

>
> On Jul 21, 2016, at 3:34 PM, Vijayakumar Badiger 
> wrote:
>
> I am trying to integrate the adb daemon by pulling in the userspace
> project from the android system/core.
> http://androidxref.com/6.0.1_r10/xref/system/core/
> When we try to compile libsync I am getting this error. Can you pls let me
> know how to overcome this. Thanks.
>
>
>
> you need to port the sync driver to kernel you are using and also it
> should be patching the kernel-headers package since it seems they are also
> exposing
> some APIs to userspace.
>
>
> On Thu, Jul 21, 2016 at 3:08 PM, Khem Raj  wrote:
>
>>
>> On Jul 21, 2016, at 2:59 PM, Burton, Ross  wrote:
>>
>>
>> On 21 July 2016 at 22:51, Vijayakumar Badiger 
>> wrote:
>>
>>> /local/mnt/workspace/c_vbadig/LV/poky/build/tmp-glibc/work/aarch64-poky-linux/system-core/git-r17/system/core/libsync/sync.c:24:24:
>>> fatal error: linux/sync.h: No such file or directory
>>> compilation terminated.
>>> make[2]: *** [libsync_la-sync.lo] Error 1
>>>
>>
>> That's not a standard user-space kernel header and doesn't appear to be a
>> standard header at all, so the question is where do you expect that header
>> to come from?
>>
>>
>> Its from android sync driver for kernel, which is not upstreamed yet.
>>
>> Ross
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error during adding a new recipe.

[Khem Raj]

> On Jul 21, 2016, at 5:20 PM, Vijayakumar Badiger  
> wrote:
> 
> The sync driver is already ported in the kernel.  I just need to get this 
> compilation error fixed. I tried adding below change to kernel bb file but 
> still I get that same error.
> 
> PACKAGES =+ "kernel-headers"
> FILES_kernel-headers = "${KDIR}/usr/include”

there is a different recipe for headers linux-libc-headers that also needs to 
be patched and then hopefully kernel build system is exporting this header for 
userspace automatically
and you will be set.

> 
> 
> Cheers
> Vijay
> 
> 
> On Thu, Jul 21, 2016 at 4:11 PM, Khem Raj  > wrote:
> 
>> On Jul 21, 2016, at 3:34 PM, Vijayakumar Badiger > > wrote:
>> 
>> I am trying to integrate the adb daemon by pulling in the userspace project 
>> from the android system/core. 
>> http://androidxref.com/6.0.1_r10/xref/system/core/ 
>> 
>> When we try to compile libsync I am getting this error. Can you pls let me 
>> know how to overcome this. Thanks.
>> 
>> 
> 
> you need to port the sync driver to kernel you are using and also it should 
> be patching the kernel-headers package since it seems they are also exposing
> some APIs to userspace.
> 
>> 
>> On Thu, Jul 21, 2016 at 3:08 PM, Khem Raj > > wrote:
>> 
>>> On Jul 21, 2016, at 2:59 PM, Burton, Ross >> > wrote:
>>> 
>>> 
>>> On 21 July 2016 at 22:51, Vijayakumar Badiger >> > wrote:
>>> /local/mnt/workspace/c_vbadig/LV/poky/build/tmp-glibc/work/aarch64-poky-linux/system-core/git-r17/system/core/libsync/sync.c:24:24:
>>>  fatal error: linux/sync.h: No such file or directory
>>> compilation terminated.
>>> make[2]: *** [libsync_la-sync.lo] Error 1
>>> 
>>> That's not a standard user-space kernel header and doesn't appear to be a 
>>> standard header at all, so the question is where do you expect that header 
>>> to come from?
>>> 
>> 
>> Its from android sync driver for kernel, which is not upstreamed yet.
>> 
>>> Ross
>>> --
>>> ___
>>> 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] Error during adding a new recipe.

[Paul Eggleton]

On Thu, 21 Jul 2016 18:22:32 Khem Raj wrote:
> > On Jul 21, 2016, at 5:20 PM, Vijayakumar Badiger 
> > wrote:
> > 
> > The sync driver is already ported in the kernel.  I just need to get this
> > compilation error fixed. I tried adding below change to kernel bb file
> > but still I get that same error.
> > 
> > PACKAGES =+ "kernel-headers"
> > FILES_kernel-headers = "${KDIR}/usr/include”
> 
> there is a different recipe for headers linux-libc-headers that also needs
> to be patched and then hopefully kernel build system is exporting this
> header for userspace automatically and you will be set.

I thought we weren't supposed to be encouraging modifying linux-libc-headers - 
especially as this isn't for the libc - it's for other userspace code...?

Cheers,
Paul

-- 

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

Re: [yocto] Error during adding a new recipe.

[Khem Raj]

On Thu, Jul 21, 2016 at 6:32 PM, Paul Eggleton
 wrote:
> On Thu, 21 Jul 2016 18:22:32 Khem Raj wrote:
>> > On Jul 21, 2016, at 5:20 PM, Vijayakumar Badiger 
>> > wrote:
>> >
>> > The sync driver is already ported in the kernel.  I just need to get this
>> > compilation error fixed. I tried adding below change to kernel bb file
>> > but still I get that same error.
>> >
>> > PACKAGES =+ "kernel-headers"
>> > FILES_kernel-headers = "${KDIR}/usr/include”
>>
>> there is a different recipe for headers linux-libc-headers that also needs
>> to be patched and then hopefully kernel build system is exporting this
>> header for userspace automatically and you will be set.
>
> I thought we weren't supposed to be encouraging modifying linux-libc-headers -
> especially as this isn't for the libc - it's for other userspace code...?

Yes thats correct thats why
I am not asking for submitting this patch upstream.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error during adding a new recipe.

[Paul Eggleton]

On Thu, 21 Jul 2016 18:35:25 Khem Raj wrote:
> On Thu, Jul 21, 2016 at 6:32 PM, Paul Eggleton
> 
>  wrote:
> > On Thu, 21 Jul 2016 18:22:32 Khem Raj wrote:
> >> > On Jul 21, 2016, at 5:20 PM, Vijayakumar Badiger
> >> > 
> >> > wrote:
> >> > 
> >> > The sync driver is already ported in the kernel.  I just need to get
> >> > this
> >> > compilation error fixed. I tried adding below change to kernel bb file
> >> > but still I get that same error.
> >> > 
> >> > PACKAGES =+ "kernel-headers"
> >> > FILES_kernel-headers = "${KDIR}/usr/include”
> >> 
> >> there is a different recipe for headers linux-libc-headers that also
> >> needs
> >> to be patched and then hopefully kernel build system is exporting this
> >> header for userspace automatically and you will be set.
> > 
> > I thought we weren't supposed to be encouraging modifying
> > linux-libc-headers - especially as this isn't for the libc - it's for
> > other userspace code...?
>
> Yes thats correct thats why
> I am not asking for submitting this patch upstream.

Sure, but this question comes up a lot. We ought to be telling people the 
correct mechanism for introducing extra headers such as this if it isn't to 
modify linux-libc-headers.

Cheers,
Paul

-- 

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

Re: [yocto] Error during adding a new recipe.

[Khem Raj]

> On Jul 21, 2016, at 6:45 PM, Paul Eggleton  
> wrote:
> 
> On Thu, 21 Jul 2016 18:35:25 Khem Raj wrote:
>> On Thu, Jul 21, 2016 at 6:32 PM, Paul Eggleton
>> 
>>  wrote:
>>> On Thu, 21 Jul 2016 18:22:32 Khem Raj wrote:
> On Jul 21, 2016, at 5:20 PM, Vijayakumar Badiger
> 
> wrote:
> 
> The sync driver is already ported in the kernel.  I just need to get
> this
> compilation error fixed. I tried adding below change to kernel bb file
> but still I get that same error.
> 
> PACKAGES =+ "kernel-headers"
> FILES_kernel-headers = "${KDIR}/usr/include”
 
 there is a different recipe for headers linux-libc-headers that also
 needs
 to be patched and then hopefully kernel build system is exporting this
 header for userspace automatically and you will be set.
>>> 
>>> I thought we weren't supposed to be encouraging modifying
>>> linux-libc-headers - especially as this isn't for the libc - it's for
>>> other userspace code...?
>> 
>> Yes thats correct thats why
>> I am not asking for submitting this patch upstream.
> 
> Sure, but this question comes up a lot. We ought to be telling people the
> correct mechanism for introducing extra headers such as this if it isn't to
> modify linux-libc-headers.

Thats possible for external kernel modules. This is a kernel patch. There is no 
other elegant way
of solving this. They could write another recipe just to stage this header. but 
thats equally ugly.

> 
> Cheers,
> Paul
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] autotool __init_array_end not found

[Takashi Matsuzawa]

Hello Yocto.

I am now trying to build autotool based (inherit autotool) recipe on Yocto 2.0 
based environent.
Howerver, I am seeng following error.
I wonder if this is a known problem and you already have workaround?

It says __init_array_end/start is not found which is referred in 
libc_nonshared.a(elf-init.oS).
I googled and learned that this can happen if parameters are not set properly 
to g++ when building shared library, and in fact, if I remove '-lc' from the 
final linker command line, the build error is gone.

>-lm -lc -lgcc_s -lgcc => NG
>-lm -lgcc_s -lgcc => OK

The problem is, these liker parameters are set by the configure script into 
libtool script and so far I could not find easy configurable option to 
explicity remove '-lc' from here.

I think configure recognizes that '-lc' is not necessary to build shared 
library (through 'build_libtool_need_lc', etc. test), but it takes these from 
somewhere (from its tests or its default template?) and embedding to linker 
command parameters.

This error did not happen with Yocto 1.8 based build (where the same recipe 
could built w/o break).
So, it can be toolchain issue (c library difference, autotool difference, etc.) 
or libc quirk, maybe fixed problem in recent versions, or specific to my 
cross-environment, but I have not yet figured out handy workaround.

I am trying here with protobuf package, butI am not yet sure if this happens 
with all of the autotool based packages.


| arm-poky-linux-gnueabi-libtool: link: arm-poky-linux-gnueabi-g++
-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15
--sysroot=/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter  -fPIC
-DPIC -shared -nostdlib
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/Scrt1.o
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/crti.o
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/arm-poky-linux-gnueabi/5.2.0/crtbeginS.o
 google/protobuf/stubs/.libs/atomicops_internals_x86_gcc.o
google/protobuf/stubs/.libs/atomicops_internals_x86_msvc.o
[...]
google/protobuf/io/.libs/zero_copy_stream_impl.o
google/protobuf/compiler/.libs/importer.o
google/protobuf/compiler/.libs/parser.o   -lpthread -lz
-L/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0
-L/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/lib
-L/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/arm-poky-linux-gnueabi/5.2.0
-L/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/libstdc++.so
-lm -lc -lgcc_s -lgcc
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/arm-poky-linux-gnueabi/5.2.0/crtendS.o
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/crtn.o
-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15
--sysroot=/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter -pthread
-O2 -g -fstack-protector-all -Wl,-O1 -Wl,--hash-style=gnu
-Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now   -pthread -Wl,-soname
-Wl,libprotobuf.so.10 -o .libs/libprotobuf.so.10.0.0
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/libc_nonshared.a(elf-init.oS):
In function `__libc_csu_init':
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/glibc/2.22-r0/git/csu/elf-init.c:89:
undefined reference to `__init_array_end'
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/glibc/2.22-r0/git/csu/elf-init.c:89:
undefined reference to `__init_array_start'
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/ld:
.libs/libprotobuf-lite.so.10.0.0: hidden symbol `__init_array_end'
isn't defined
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/ld:
final link failed: Bad value
| collect2: error: ld returned 1 exit status
| Makefile:1492: recipe for target 'libprotobuf-lite.la' failed
| make[3]: *** [libprotobuf-lite.la] Error 1
| make[3]: *** Waiting for unfinished jobs
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/libc_nonshared.a(elf-init.oS):
In function `__libc_csu_init':
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/glibc/2.22-r0/git/csu/elf-init.c:89:
undefined reference to `__init_array_end'
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/glibc/2.22-r0/git/csu/elf-init.c:89:
undefined reference to `__init_array_start'
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/ld:
.libs/libprotobuf.so.10.0.0: hidden symbol `__init_array_end' isn't
defined
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/ld:
final link failed: Bad value
| collect2: error: ld returned 1 exit st