[yocto] [meta-raspberrypi] Disable kernel option via fragment Rpi3

2016-06-24 Thread Jonathan Haws 
I'm trying to build an image for an Rpi3 and am having some difficulty.

I've created and posted a meta-batman layer to bring the latest BATMAN 
Advanced module and userspace tools to Yocto.  I haven't had any 
troubles getting this layer to work with other architectures, but am 
having troubles with the Raspberry Pi.

The error I am getting is at the end of this email.  I believe it has to 
do with the fact that the kernel configuration has the BATMAN module 
enabled, but I am trying to build it externally.  I've tried adding 
kernel configuration fragments to disable this option, but with no luck.

I found that if I add "kernel_configure_variable CONFIG_BATMAN_ADV n" to 
linux-rpi.inc the command kernel_configme will show that the option is 
disabled in the generated .config, but when I try to build an image I 
get the same error and the configuration has the module enabled again.

What is the best way to use fragments with Raspberry Pi images?  Am I 
missing something?

Thanks!
Jon



ERROR: The recipe linux-raspberrypi is trying to install files into a 
shared area when those files already exist. Those files and their 
manifest location are:
 
/opt/yocto/poky/build-pi/tmp/sysroots/raspberrypi3/pkgdata/runtime/kernel-module-batman-adv
  Matched in manifest-raspberrypi3-batman-adv.packagedata
 
/opt/yocto/poky/build-pi/tmp/sysroots/raspberrypi3/pkgdata/runtime/kernel-module-batman-adv.packaged
  Matched in manifest-raspberrypi3-batman-adv.packagedata
 
/opt/yocto/poky/build-pi/tmp/sysroots/raspberrypi3/pkgdata/runtime-reverse/kernel-module-batman-adv
  Matched in manifest-raspberrypi3-batman-adv.packagedata
Please verify which recipe should provide the above files.
The build has stopped as continuing in this scenario WILL break things, 
if not now, possibly in the future (we've seen builds fail several 
months later). If the system knew how to recover from this automatically 
it would however there are several different scenarios which can result 
in this and we don't know which one this is. It may be you have switched 
providers of something like virtual/kernel (e.g. from linux-yocto to 
linux-yocto-dev), in that case you need to execute the clean task for 
both recipes and it will resolve this error. It may be you changed 
DISTRO_FEATURES from systemd to udev or vice versa. Cleaning those 
recipes should again resolve this error however switching 
DISTRO_FEATURES on an existing build directory is not supported, you 
should really clean out tmp and rebuild (reusing sstate should be safe). 
It could be the overlapping files detected are harmless in which case 
adding them to SSTATE_DUPWHITELIST may be the correct solution. It could 
also be your build is including two different conflicting versions of 
things (e.g. bluez 4 and bluez 5 and the correct solution for that would 
be to resolve the conflict. If in doubt, please ask on the mailing list, 
sharing the error and filelist above.
ERROR: If the above message is too much, the simpler version is you're 
advised to wipe out tmp and rebuild (reusing sstate is fine). That will 
likely fix things in most (but not all) cases.
ERROR: Function failed: sstate_task_postfunc
ERROR: Logfile of failure stored in: 
/opt/yocto/poky/build-pi/tmp/work/raspberrypi3-sigma-linux-gnueabi/linux-raspberrypi/1_4.1.21+gitAUTOINC+ff45bc0e89-r0/temp/log.do_packagedata.123616
ERROR: Task 57 
(/opt/yocto/poky/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.1.bb,
 
do_packagedata) failed with exit code '1'



-- 
Jonathan R. Haws
Embedded Engineer
Space Dynamics Laboratory
jh...@sdl.usu.edu
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] go toolchain

2016-06-24 Thread Khem Raj 
can you try

https://github.com/kraj/oe-meta-go/commits/master 


> On Jun 24, 2016, at 4:06 PM, Sridhar Pitchai  
> wrote:
> 
> Hi,
> does someone have good go meta layer. I have experimented with meta-go and 
> meta-golang, not able to make it work it.
> 
> meta-go : bootstrap 1.4 works but the native go 1.5.3 not working.
> 
> meta-golang: i am not able to make it work even with qemu x86.
> 
> any suggestion appreciated.
> 
> Thanks,
> Sridhar
> --
> ___
> 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] go toolchain

2016-06-24 Thread Sridhar Pitchai 
Hi,does someone have good go meta layer. I have experimented with meta-go and 
meta-golang, not able to make it work it. 
meta-go : bootstrap 1.4 works but the native go 1.5.3 not working. 
meta-golang: i am not able to make it work even with qemu x86. 
any suggestion appreciated. 
Thanks,Sridhar-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 0/3] kernel-cache: vfat feature cleanup

2016-06-24 Thread Bruce Ashfield 

On 2016-06-24 11:28 AM, Tom Zanussi wrote:

This is a small patchset for yocto-4.4 that removes open-coded VFAT_FS
and enables defaults that should be enabled along with it.


Thanks Tom.

These looked sane to me, so I pulled them into all the branches so
the behaviour would be consistent (i.e. 4.1, 4.4, 4.6 and master).

SRCREVs will be bumped when I send my next consolidated queue.

Cheers,

Bruce



The following changes since commit 870134f4bfa6208d6e5339e065486be3b6e693a5:

   kver: bump to v4.4.14 (2016-06-10 13:18:02 -0400)

are available in the git repository at:

   git://git.yoctoproject.org/linux-yocto-contrib.git 
tzanussi/kernel-cache-4.4-vfat
   
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=tzanussi/kernel-cache-4.4-vfat

Tom Zanussi (3):
   cfg/fs/vfat: Enable NLS defaults
   cfg/usb-mass-storage: Use vfat feature
   cfg/boot-live: Use vfat feature

  cfg/boot-live.cfg| 3 ---
  cfg/boot-live.scc| 2 ++
  cfg/fs/vfat.cfg  | 3 +++
  cfg/usb-mass-storage.cfg | 2 --
  cfg/usb-mass-storage.scc | 1 +
  5 files changed, 6 insertions(+), 5 deletions(-)



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

Re: [linux-yocto] [PATCH 0/3] ACPI fixes for standard/intel/* branches

2016-06-24 Thread Bruce Ashfield 

On 2016-06-23 10:26 PM, California Sullivan wrote:

Hi Bruce,

These patches (not yet upstream) fix a bug with ACPI device
enumeration that we hit on some of our Broxton boards. Please
apply them to the linux-yocto-4.4 Intel branches.


Applied to standard/intel/base and standard/preempt-rt/intel/base

Once I do a quick sanity test, I'll push the changes.

Bruce



Thanks,
Cal Sullivan

Octavian Purdila (3):
   acpi: fix enumeration (visited) flags for bus rescans
   acpi: add support for ACPI reconfiguration notifiers
   i2c: add support for ACPI reconfigure notifications

  drivers/acpi/bus.c  |   9 +++
  drivers/acpi/internal.h |   3 +
  drivers/acpi/scan.c |  81 +--
  drivers/acpi/sysfs.c|   6 +-
  drivers/i2c/i2c-core.c  | 172 +---
  include/linux/acpi.h|  36 ++
  6 files changed, 258 insertions(+), 49 deletions(-)



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

Re: [linux-yocto] [PATCH 0/2] Use CPUID to estimate clock frequency for linux-yocto-4.1

2016-06-24 Thread Bruce Ashfield 

On 2016-06-23 12:25 AM, Yong, Jonathan wrote:

This patch allows clock frequencies to be calibrated if TSC and CPU
frequencies differ. This is not in the latest kernel tree yet, so this
should go into standard/intel/base.


staged to standard/intel/base

Bruce



Tested with Apollo Lake.

Bin Gao (1):
   x86 tsc: enumerate BXT tsc_khz via CPUID

Len Brown (1):
   x86 tsc: enumerate SKL cpu_khz and tsc_khz via CPUID

  arch/x86/include/asm/tsc.h  |  1 +
  arch/x86/include/asm/x86_init.h |  4 +-
  arch/x86/kernel/tsc.c   | 91 +
  arch/x86/kernel/x86_init.c  |  1 +
  4 files changed, 89 insertions(+), 8 deletions(-)



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

Re: [linux-yocto] [PATCH 0/2] Use CPUID to estimate clock frequency for linux-yocto-4.1

2016-06-24 Thread Bruce Ashfield 

On 2016-06-23 03:55 PM, Saul Wold wrote:

Bruce, I think we need these in 4.4 bxt-rebase also.


I tried to apply them to that branch, but they failed. If someone
sends me the patches again, I can apply them there.

Bruce



They are pending in Lenb's tree.

Sau!

On Thu, 2016-06-23 at 04:25 +, Yong, Jonathan wrote:


This patch allows clock frequencies to be calibrated if TSC and CPU
frequencies differ. This is not in the latest kernel tree yet, so
this
should go into standard/intel/base.

Tested with Apollo Lake.

Bin Gao (1):
   x86 tsc: enumerate BXT tsc_khz via CPUID

Len Brown (1):
   x86 tsc: enumerate SKL cpu_khz and tsc_khz via CPUID

  arch/x86/include/asm/tsc.h  |  1 +
  arch/x86/include/asm/x86_init.h |  4 +-
  arch/x86/kernel/tsc.c   | 91
+
  arch/x86/kernel/x86_init.c  |  1 +
  4 files changed, 89 insertions(+), 8 deletions(-)

--
2.7.3



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

Re: [linux-yocto] [PATCH] back port "platform:x86 decouple telemetry driver from the optional IPC resources"

2016-06-24 Thread Bruce Ashfield 

On 2016-06-23 03:25 AM, ong.hock...@intel.com wrote:

From: "Yu, Ong Hock" 

Backport patch "platform:x86 decouple telemetry driver from the optional IPC 
resources" from upstream to 4.1 standard/base



staged.

Bruce


Aubrey Li (1):
   platform:x86 decouple telemetry driver from the optional IPC resources

  drivers/platform/x86/intel_pmc_ipc.c   | 48 --
  drivers/platform/x86/intel_punit_ipc.c | 48 ++
  2 files changed, 54 insertions(+), 42 deletions(-)



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

Re: [yocto] question: yocto-bsp tool warnings

2016-06-24 Thread Jake Swensen 
Worked on jethro (and it's already in krogoth). Git detected a conflict that I 
think was only white 
space.


>From b01d2e26bb038240fb609ef78727696c729711ba Mon Sep 17 00:00:00 2001
From: Bruce Ashfield 
Date: Thu, 21 Apr 2016 11:23:45 -0400
Subject: [PATCH] kernel-yocto: allow branch auditing to be suspended


When working on the yocto-bsp and kernel-lab update for yocto 1.2
we found it was impossible for a end-user BSP to isolate patches
on a branch, since with the following commit:


  [kernel-yocto: enforce SRC_URI specified branch]


Any new branch would be switched to whatever was specified on the
SRC_URI and undoing the work that the yocto-bsp tool did to support
board specific patches.


To fix this, we'll keep the enforcing of branch consistency enabled
by default, but introduce a variable "KMETA_AUDIT" that when not
set will skip the check.


There's no impact for existing users, and it is only something that
other plumbing commands and tools will need to use (or care about).


[YOCTO: #9120]


(From OE-Core rev: 1d4c120edeb6e45665eafd6962a10ebb89d758eb)


Signed-off-by: Bruce Ashfield 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 


Conflicts:
meta/classes/kernel-yocto.bbclass
---
 meta/classes/kernel-yocto.bbclass         | 16 
 meta/recipes-kernel/linux/linux-yocto.inc |  1 +
 2 files changed, 17 insertions(+)


diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index c2d0d30..c6431a4 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -170,6 +170,22 @@ do_patch() {
    fi
    fi
 
+        if [ -n "${KMETA_AUDIT}" ]; then
+            current_branch=`git rev-parse --abbrev-ref HEAD`
+            machine_branch="${@ get_machine_branch(d, "${KBRANCH}" )}"
+            if [ "${current_branch}" != "${machine_branch}" ]; then
+                bbwarn "After meta data application, the kernel tree branch is 
${current_branch}."
+                bbwarn "The SRC_URI specified branch ${machine_branch}."
+                bbwarn ""
+                bbwarn "The branch will be forced to ${machine_branch}, but 
this means the board meta data"
+                bbwarn "(.scc files) do not match the SRC_URI specification."
+                bbwarn ""
+                bbwarn "The meta data and branch ${machine_branch} should be 
inspected to ensure the proper"
+                bbwarn "kernel is being built."
+                git checkout -f ${machine_branch}
+            fi
+        fi
+
    if [ "${machine_srcrev}" != "AUTOINC" ]; then
    if ! [ "$(git rev-parse --verify ${machine_srcrev}~0)" = "$(git 
merge-base ${machine_srcrev} HEAD)" ]; then
    bberror "SRCREV ${machine_srcrev} was specified, but is 
not reachable"
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc 
b/meta/recipes-kernel/linux/linux-yocto.inc
index 81ffa24..1e383c8 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -33,6 +33,7 @@ SRCREV_FORMAT ?= "meta_machine"
 #   2: report options that are not hardware related, but set by a BSP
 KCONF_AUDIT_LEVEL ?= "1"
 KCONF_BSP_AUDIT_LEVEL ?= "0"
+KMETA_AUDIT ?= "yes"
 
 LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}"
 
-- 
1.9.1







From: Bruce Ashfield 
Sent: Friday, June 24, 2016 9:36 AM
To: Jake Swensen; yocto@yoctoproject.org
Subject: [EXTERNAL] Re: [yocto] question: yocto-bsp tool warnings
    
On 2016-06-23 05:52 PM, Jake Swensen wrote:
> I've been looking into setting up my own BSP layer based on the
> standard/beaglebone branch and I've run into some warnings I wasn't familiar
> with. I created a test BSP with the yocto-bsp tool and set MACHINE=test,
> (which is the name of my meta layer) then ran it. This produced several
> warnings:
>
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: 
> After meta data application, the kernel tree branch is standard/test.
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: 
> The SRC_URI specified branch standard/base.
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch:
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: 
> The branch will be forced to standard/base, but this means the board meta data
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: 
> (.scc files) do not match the SRC_URI specification.
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch:
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: 
> The meta data and branch standard/base should be inspected to ensure the 
> proper
> WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: 
> kernel is being built.
>
> I

[linux-yocto] [PATCH 0/3] kernel-cache: vfat feature cleanup

2016-06-24 Thread Tom Zanussi 
This is a small patchset for yocto-4.4 that removes open-coded VFAT_FS
and enables defaults that should be enabled along with it.

The following changes since commit 870134f4bfa6208d6e5339e065486be3b6e693a5:

  kver: bump to v4.4.14 (2016-06-10 13:18:02 -0400)

are available in the git repository at:

  git://git.yoctoproject.org/linux-yocto-contrib.git 
tzanussi/kernel-cache-4.4-vfat
  
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/log/?h=tzanussi/kernel-cache-4.4-vfat

Tom Zanussi (3):
  cfg/fs/vfat: Enable NLS defaults
  cfg/usb-mass-storage: Use vfat feature
  cfg/boot-live: Use vfat feature

 cfg/boot-live.cfg| 3 ---
 cfg/boot-live.scc| 2 ++
 cfg/fs/vfat.cfg  | 3 +++
 cfg/usb-mass-storage.cfg | 2 --
 cfg/usb-mass-storage.scc | 1 +
 5 files changed, 6 insertions(+), 5 deletions(-)

-- 
1.9.3

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

[linux-yocto] [PATCH 3/3] cfg/boot-live: Use vfat feature

2016-06-24 Thread Tom Zanussi 
Use the vfat feature instead of directly configuring it.

The vfat feature also now includes enabling the NLS defaults for
VFAT_FS, so remove them here.

Signed-off-by: Tom Zanussi 
---
 cfg/boot-live.cfg | 3 ---
 cfg/boot-live.scc | 2 ++
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/cfg/boot-live.cfg b/cfg/boot-live.cfg
index 56041a9..b90875d 100644
--- a/cfg/boot-live.cfg
+++ b/cfg/boot-live.cfg
@@ -1,7 +1,4 @@
 CONFIG_BLK_DEV_LOOP=y
-CONFIG_NLS_CODEPAGE_437=y
-CONFIG_NLS_ISO8859_1=y
-CONFIG_VFAT_FS=y
 CONFIG_RD_GZIP=y
 # Needed for booting (and using) CD images
 CONFIG_BLK_DEV_IDECD=y
diff --git a/cfg/boot-live.scc b/cfg/boot-live.scc
index 2d47d6c..70fda3f 100644
--- a/cfg/boot-live.scc
+++ b/cfg/boot-live.scc
@@ -1,4 +1,6 @@
 define KFEATURE_DESCRIPTION "Live boot support"
 define KFEATURE_COMPATIBILITY arch
 
+include cfg/fs/vfat.scc
+
 kconf non-hardware boot-live.cfg
-- 
1.9.3

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

[linux-yocto] [PATCH 2/3] cfg/usb-mass-storage: Use vfat feature

2016-06-24 Thread Tom Zanussi 
Use the vfat feature instead of directly configuring it.

FAT_FS is automatically selected by VFAT_FS as well as MSDOS_FS, so
remove it here.

Signed-off-by: Tom Zanussi 
---
 cfg/usb-mass-storage.cfg | 2 --
 cfg/usb-mass-storage.scc | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/cfg/usb-mass-storage.cfg b/cfg/usb-mass-storage.cfg
index abd9712..7f18681 100644
--- a/cfg/usb-mass-storage.cfg
+++ b/cfg/usb-mass-storage.cfg
@@ -3,6 +3,4 @@
 # per-BSP enablement.
 
 CONFIG_USB_STORAGE=y
-CONFIG_VFAT_FS=y
-CONFIG_FAT_FS=y
 CONFIG_MSDOS_FS=y
diff --git a/cfg/usb-mass-storage.scc b/cfg/usb-mass-storage.scc
index aed330c..8fe5ba5 100644
--- a/cfg/usb-mass-storage.scc
+++ b/cfg/usb-mass-storage.scc
@@ -2,5 +2,6 @@ define KFEATURE_DESCRIPTION "Enable options required for USB 
mass storage device
 define KFEATURE_COMPATIBILITY all
 
 include features/scsi/disk.scc
+include cfg/fs/vfat.scc
 
 kconf non-hardware usb-mass-storage.cfg
-- 
1.9.3

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

[linux-yocto] [PATCH 1/3] cfg/fs/vfat: Enable NLS defaults

2016-06-24 Thread Tom Zanussi 
VFAT_FS defaults to codepage 437 and iso8559-1, but doesn't enable
the NLS support, so have the feature do it.

Signed-off-by: Tom Zanussi 
---
 cfg/fs/vfat.cfg | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/cfg/fs/vfat.cfg b/cfg/fs/vfat.cfg
index 18979aa..f0da6af 100644
--- a/cfg/fs/vfat.cfg
+++ b/cfg/fs/vfat.cfg
@@ -1,2 +1,5 @@
 CONFIG_VFAT_FS=y
 
+# VFAT_FS selects these as the default, so they should be enabled
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
-- 
1.9.3

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

[yocto] Yocto Project Status WW26

2016-06-24 Thread Jolley, Stephen K 
Current Dev Position: YP 2.2 M2

Next Deadline: YP 2.2 M2 cut off would be: 7/18/16


SWAT team rotation: Joshua -> Armin

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

*After delays in addressing several issues, a build of 2.2 M1 went into 
QA and is undergoing testing. Whilst M1 was late, many good bug fixes were 
merged so it was worth the delay.

*Testing so far seems positive except for reports of some wic issues.

*Some merging of patches for M2 is now underway.

*The multi-config builds patchset is maturing and now basically works, 
it needs splitting up and submitting. The major missing piece of functionality 
is inter-multi-config dependency support.


Key YP 2.2 Dates:

*YP 2.2 M1 release would be: 6/24/16

*YP 2.2 M2 cut off would be: 7/18/16

*YP 2.2 M2 release would be: 7/29/16

*YP 2.2 M3 cut off would be: 8/29/16

*YP 2.2 M3 release would be: 9/9/16

*YP 2.2 M4 cut off would be: 10/3/16

*YP 2.2 M4 release would be: 10/28/16


Tracking Metrics:

WDD 2745 (last week 2678)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.2_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.2_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.2_Features

[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

[yocto] [autobuilder][PATCH] nightly-arm.conf: build Cortex-A8 toolchains

2016-06-24 Thread Bill Randle 
Since met-fsl-arm was dropped from the nightly builds, the Cortex-A8 cross-
compiler used for beaglebone builds is not created. Include toochain
builds as part of nightly-arm now, so compiler is available for users
of the beaglebone machine.

[YOCTO #9810]

Signed-off-by: Bill Randle 
---
 buildset-config.controller/nightly-arm.conf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/buildset-config.controller/nightly-arm.conf 
b/buildset-config.controller/nightly-arm.conf
index 76244ed..32920cf 100644
--- a/buildset-config.controller/nightly-arm.conf
+++ b/buildset-config.controller/nightly-arm.conf
@@ -15,7 +15,11 @@ steps: [{'SetDest':{}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
 {'RunSanityTests': {'images': 'core-image-minimal core-image-sato 
core-image-sato-sdk'}},
 {'CreateAutoConf': {'machine': 'beagleboard', 'SDKMACHINE' : 'i686', 
'distro': 'poky'}},
+{'BuildToolchainImages': {}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk core-image-minimal core-image-minimal-dev 
core-image-sato-sdk-ptest'}},
+{'CreateAutoConf': {'machine': 'beagleboard', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky'}},
+{'BuildToolchainImages': {}},
+{'BuildImages': {'images': '-c populate_sdk_ext core-image-minimal'}},
 {'CreateAutoConf': {'machine': 'qemuarm', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'buildhistory' : False}},
 {'BuildToolchainImages': {}},
 {'RunSDKSanityTests': {'images': 'core-image-sato'}},
-- 
2.5.5

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

Re: [yocto] question: yocto-bsp tool warnings

2016-06-24 Thread Bruce Ashfield 

On 2016-06-23 05:52 PM, Jake Swensen wrote:

I've been looking into setting up my own BSP layer based on the
standard/beaglebone branch and I've run into some warnings I wasn't familiar
with. I created a test BSP with the yocto-bsp tool and set MACHINE=test,
(which is the name of my meta layer) then ran it. This produced several
warnings:

WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: 
After meta data application, the kernel tree branch is standard/test.
WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: The 
SRC_URI specified branch standard/base.
WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch:
WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: The 
branch will be forced to standard/base, but this means the board meta data
WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: 
(.scc files) do not match the SRC_URI specification.
WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch:
WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: The 
meta data and branch standard/base should be inspected to ensure the proper
WARNING: linux-yocto-4.4.10+gitAUTOINC+870134f4bf_13852755ec-r0.1 do_patch: 
kernel is being built.

I found the patch which enabled this warning, but I'm unsure how to alleviate
it. I do intend to use the standard/test branch, but I'm not sure which
SRC_URI is telling bitbake to build the standard/base.


I'm actively changing the code in this area, so what I'm about to
describe will be valid for about a month, and then it'll be simpler
to explain.

When you are building linux-yocto BSPs (as the yocto-bsp tool is
manipulating) there are two ways that what is build is specifiied:
the SRC_URI (bitbake, the fetcher, etc) and kernel meta-data (the
kernel-cache repository you see on the SRC_URI).

The SRC_URI must specify a branch and SRCREV, since the fetcher
requires it, and that is typically what is built (hence no warning).

But the kernel meta data also has a complete description of the
tree structure (the branching standard/base, standard/common-pc, etc),
since it validates and can re-construct the tree from scratch.

So if the recipe and meta-data disagree on the branch that is to
be built, that warning is displayed, just so there are no surprises.

It is completely valid to build something different than the kernel
meta data describes, which is why the flag KMETA_AUDIT was also
added. When it is set to a non-zero valid, the auditing happens, but
if you clear it in your bbappend, you'll no longer see the warning.

But that commit 1ce221da64e21b9ee0a743dc9372236ab22e21ba (poky), is
only in master. I should get it nominated for backporting to the
release branches. IF you cherry-pick and try it out, that would be
helpful.

Cheers,

Bruce




Any idea where to start looking?

Patch that enabled the warnings: 
http://lists.openembedded.org/pipermail/openembedded-core/2016-April/119808.html






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

[yocto] [meta-java] How is the version string in openjdk/openjre built

2016-06-24 Thread Bernhard Dick 
Hi,

currently I'm facing a small problem with the meta-java package. I have
applications that check the version string of java for specific releases.
The string from java -version built with the meta-java package however does
not include that but results in 1.8.0-native or 1.8.0-internal.
So I wanted to fix it and include the release number. However, maybe due to
I'm quite new with the openembedded build system, I cannot find, where the
version is changed within the layer, I also do not see where the -native or
-internal string is coming from. It appears later within the MILESTONE
variable of the build config. Can you help me on this topic?
  Regards
Bernhard Dick


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

Re: [yocto] setcap using recipe

2016-06-24 Thread Burton, Ross 
Looks like using setcap directly is broken currently, there are two
workarounds:

1) use a postinst to invoke setcap on the target instead
2) test the patch for pseudo that is on this list ([PATCH] Add capset
pseudo function that always succeeds) and verify that it fixes the problem
for you.

Ross

On 24 June 2016 at 13:31, Kumar, Shrawan  wrote:

> I am using Yocto 2.0.2
>
>
>
> Thanks and Regards
>
> Shrawan
>
>
>
> *From:* Burton, Ross [mailto:ross.bur...@intel.com]
> *Sent:* Friday, June 24, 2016 5:56 PM
>
> *To:* Kumar, Shrawan
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] setcap using recipe
>
>
>
> What version of OE/Yocto are you using?  Old versions of pseudo didn't
> support xattrs at all.
>
>
>
> Ross
>
>
>
> On 24 June 2016 at 13:23, Kumar, Shrawan  wrote:
>
> Thanks Ross for your quick turn around , I am getting below error
>
>
>
> “Unable le to set CAP_SETFCAP effective capability: Operation not
> permitted.”
>
>
>
> But when I use# *sudo* setcap cap_net_raw+ep  helloworldon
> command line I am able to set the cap.
>
>
>
> To achieve the sudo realization  in recipe , I tried  as below , but no
> luck…… Can you suggest something here  ?
>
>
>
> fakeroot do_install() {
>
> install -d ${D}${bindir}
>
> install -m 0755 helloworld ${D}${bindir}
>
> install -d ${D}/lib/systemd/system
>
> install -m 0755 hello.service ${D}/lib/systemd/system/
>
>  setcap cap_net_raw+ep  ${D}${bindir}/helloworld
>
>
>
> }
>
>
>
> Thanks and Regards
>
> Shrawan
>
>
>
> *From:* Burton, Ross [mailto:ross.bur...@intel.com]
> *Sent:* Friday, June 24, 2016 5:09 PM
> *To:* Kumar, Shrawan
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] setcap using recipe
>
>
>
> Hi,
>
>
>
> On 24 June 2016 at 11:41, Kumar, Shrawan  wrote:
>
> Is there a way to  add a capability to a binary (cap_net_raw+ep),into a
> recipe?
>
>
>
> Example :
>
> do_install() {
>
>install -d ${D}${bindir}
>
>install -m 0755 helloworld ${D}${bindir}
>
>install -d ${D}/lib/systemd/system
>
>install -m 0755 hello.service ${D}/lib/systemd/system/
>
>setcap cap_net_raw+ep  ${D}${bindir}/helloworld
>
> }
>
>
>
> If yes is this correct approach to achieve the same from  package recipe
> itself ?
>
>
> capabilities on files are just extended attributes, so assuming that you
> have a fairly recent Yocto and your host and target filesystems support
> extended attributes, yes this should work.
>
>
>
> Ross
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [pseudo][PATCH] Add capset pseudo function that always succeeds

2016-06-24 Thread Burton, Ross 
I just discovered that this was never merged, Peter can you review it?

Ross

On 3 May 2016 at 14:18, George McCollister 
wrote:

> The setcap utility supplied by libcap is used to set capabilities on a
> file. Before setting a file's capabilities with cap_set_file() (which uses
> setxattr()) it calls cap_set_flag(mycaps, CAP_EFFECTIVE, 1, ,
> CAP_SET). cap_set_flag() uses the capset syscall to raise the process'
> effective capability. In most cases if the process isn't running as root
> this will fail and setcap will exit with an error. Because setxattr is
> intercepted by pseudo it's unnecessary for setcap to call capset().
>
> Override capset with a pseudo function that does nothing and always
> returns 0.
>
> Signed-off-by: George McCollister 
> ---
>  ports/linux/guts/capset.c | 13 +
>  ports/linux/portdefs.h|  2 ++
>  ports/linux/pseudo_wrappers.c |  7 +++
>  ports/linux/wrapfuncs.in  |  1 +
>  4 files changed, 23 insertions(+)
>  create mode 100644 ports/linux/guts/capset.c
>
> diff --git a/ports/linux/guts/capset.c b/ports/linux/guts/capset.c
> new file mode 100644
> index 000..51e0cdf
> --- /dev/null
> +++ b/ports/linux/guts/capset.c
> @@ -0,0 +1,13 @@
> +/*
> + * Copyright (c) 2016 Wind River Systems; see
> + * guts/COPYRIGHT for information.
> + *
> + * int capset(cap_user_header_t hdrp, const cap_user_data_t datap)
> + * int rc = -1;
> + */
> +
> +   rc = real_capset(hdrp, datap);
> +
> +/* return rc;
> + * }
> + */
> diff --git a/ports/linux/portdefs.h b/ports/linux/portdefs.h
> index f0a0e40..d8c5020 100644
> --- a/ports/linux/portdefs.h
> +++ b/ports/linux/portdefs.h
> @@ -25,3 +25,5 @@ GLIBC_COMPAT_SYMBOL(memcpy,2.2.5);
>  #elif defined(__i386__)
>  GLIBC_COMPAT_SYMBOL(memcpy,2.0);
>  #endif
> +
> +#include 
> diff --git a/ports/linux/pseudo_wrappers.c b/ports/linux/pseudo_wrappers.c
> index 26b29b0..c6c072b 100644
> --- a/ports/linux/pseudo_wrappers.c
> +++ b/ports/linux/pseudo_wrappers.c
> @@ -31,3 +31,10 @@ int
>  pseudo_fstat64(int fd, struct stat64 *buf) {
> return real___fxstat64(_STAT_VER, fd, buf);
>  }
> +
> +int pseudo_capset(cap_user_header_t hdrp, const cap_user_data_t datap) {
> +   (void)hdrp;
> +   (void)datap;
> +
> +   return 0;
> +}
> diff --git a/ports/linux/wrapfuncs.in b/ports/linux/wrapfuncs.in
> index 3b8955a..578db35 100644
> --- a/ports/linux/wrapfuncs.in
> +++ b/ports/linux/wrapfuncs.in
> @@ -51,3 +51,4 @@ int euidaccess(const char *path, int mode);
>  int getpw(uid_t uid, char *buf);
>  int getpwent_r(struct passwd *pwbuf, char *buf, size_t buflen, struct
> passwd **pwbufp);
>  int getgrent_r(struct group *gbuf, char *buf, size_t buflen, struct group
> **gbufp);
> +int capset(cap_user_header_t hdrp, const cap_user_data_t datap); /*
> real_func=pseudo_capset */
> --
> 2.8.0
>
> --
> ___
> 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] is override for UBOOT_MACHINE_mpc8315e-rdb = "MPC8315ERDB_config" necessary?

2016-06-24 Thread Robert P. J. Day 

  poking around UBOOT_CONFIG and UBOOT_MACHINE and, in meta-yocto-bsp,
i notice the two examples of UBOOT_MACHINE being set:

 beaglebone.conf:UBOOT_MACHINE = "am335x_evm_config"
 mpc8315e-rdb.conf:UBOOT_MACHINE_mpc8315e-rdb = "MPC8315ERDB_config"

while i'm sure it doesn't hurt, is there a reason for the machine
override being added for mpc8315e.rdb? after all, it matches exactly
the machine name, and i don't see any other machine based on that
.conf file.

  is there some rationale for those two forms to be different?

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

Re: [yocto] setcap using recipe

2016-06-24 Thread Kumar, Shrawan 
I am using Yocto 2.0.2

Thanks and Regards
Shrawan

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, June 24, 2016 5:56 PM
To: Kumar, Shrawan
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] setcap using recipe

What version of OE/Yocto are you using?  Old versions of pseudo didn't support 
xattrs at all.

Ross

On 24 June 2016 at 13:23, Kumar, Shrawan 
> wrote:
Thanks Ross for your quick turn around , I am getting below error

“Unable le to set CAP_SETFCAP effective capability: Operation not permitted.”

But when I use# sudo setcap cap_net_raw+ep  helloworldon command 
line I am able to set the cap.

To achieve the sudo realization  in recipe , I tried  as below , but no luck…… 
Can you suggest something here  ?

fakeroot do_install() {
install -d ${D}${bindir}
install -m 0755 helloworld ${D}${bindir}
install -d ${D}/lib/systemd/system
install -m 0755 hello.service ${D}/lib/systemd/system/
 setcap cap_net_raw+ep  ${D}${bindir}/helloworld

}

Thanks and Regards
Shrawan

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, June 24, 2016 5:09 PM
To: Kumar, Shrawan
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] setcap using recipe

Hi,

On 24 June 2016 at 11:41, Kumar, Shrawan 
> wrote:

Is there a way to  add a capability to a binary (cap_net_raw+ep),into a recipe?


Example :

do_install() {

   install -d ${D}${bindir}

   install -m 0755 helloworld ${D}${bindir}

   install -d ${D}/lib/systemd/system

   install -m 0755 hello.service ${D}/lib/systemd/system/

   setcap cap_net_raw+ep  ${D}${bindir}/helloworld

}



If yes is this correct approach to achieve the same from  package recipe itself 
?

capabilities on files are just extended attributes, so assuming that you have a 
fairly recent Yocto and your host and target filesystems support extended 
attributes, yes this should work.

Ross



HelloWorld_0.1.bb
Description: HelloWorld_0.1.bb
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] setcap using recipe

2016-06-24 Thread Burton, Ross 
What version of OE/Yocto are you using?  Old versions of pseudo didn't
support xattrs at all.

Ross

On 24 June 2016 at 13:23, Kumar, Shrawan  wrote:

> Thanks Ross for your quick turn around , I am getting below error
>
>
>
> “Unable le to set CAP_SETFCAP effective capability: Operation not
> permitted.”
>
>
>
> But when I use# *sudo* setcap cap_net_raw+ep  helloworldon
> command line I am able to set the cap.
>
>
>
> To achieve the sudo realization  in recipe , I tried  as below , but no
> luck…… Can you suggest something here  ?
>
>
>
> fakeroot do_install() {
>
> install -d ${D}${bindir}
>
> install -m 0755 helloworld ${D}${bindir}
>
> install -d ${D}/lib/systemd/system
>
> install -m 0755 hello.service ${D}/lib/systemd/system/
>
>  setcap cap_net_raw+ep  ${D}${bindir}/helloworld
>
>
>
> }
>
>
>
> Thanks and Regards
>
> Shrawan
>
>
>
> *From:* Burton, Ross [mailto:ross.bur...@intel.com]
> *Sent:* Friday, June 24, 2016 5:09 PM
> *To:* Kumar, Shrawan
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] setcap using recipe
>
>
>
> Hi,
>
>
>
> On 24 June 2016 at 11:41, Kumar, Shrawan  wrote:
>
> Is there a way to  add a capability to a binary (cap_net_raw+ep),into a
> recipe?
>
>
>
> Example :
>
> do_install() {
>
>install -d ${D}${bindir}
>
>install -m 0755 helloworld ${D}${bindir}
>
>install -d ${D}/lib/systemd/system
>
>install -m 0755 hello.service ${D}/lib/systemd/system/
>
>setcap cap_net_raw+ep  ${D}${bindir}/helloworld
>
> }
>
>
>
> If yes is this correct approach to achieve the same from  package recipe
> itself ?
>
>
> capabilities on files are just extended attributes, so assuming that you
> have a fairly recent Yocto and your host and target filesystems support
> extended attributes, yes this should work.
>
>
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] setcap using recipe

2016-06-24 Thread Kumar, Shrawan 
Thanks Ross for your quick turn around , I am getting below error

“Unable le to set CAP_SETFCAP effective capability: Operation not permitted.”

But when I use# sudo setcap cap_net_raw+ep  helloworldon command 
line I am able to set the cap.

To achieve the sudo realization  in recipe , I tried  as below , but no luck…… 
Can you suggest something here  ?

fakeroot do_install() {
install -d ${D}${bindir}
install -m 0755 helloworld ${D}${bindir}
install -d ${D}/lib/systemd/system
install -m 0755 hello.service ${D}/lib/systemd/system/
 setcap cap_net_raw+ep  ${D}${bindir}/helloworld

}

Thanks and Regards
Shrawan

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, June 24, 2016 5:09 PM
To: Kumar, Shrawan
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] setcap using recipe

Hi,

On 24 June 2016 at 11:41, Kumar, Shrawan 
> wrote:

Is there a way to  add a capability to a binary (cap_net_raw+ep),into a recipe?


Example :

do_install() {

   install -d ${D}${bindir}

   install -m 0755 helloworld ${D}${bindir}

   install -d ${D}/lib/systemd/system

   install -m 0755 hello.service ${D}/lib/systemd/system/

   setcap cap_net_raw+ep  ${D}${bindir}/helloworld

}



If yes is this correct approach to achieve the same from  package recipe itself 
?

capabilities on files are just extended attributes, so assuming that you have a 
fairly recent Yocto and your host and target filesystems support extended 
attributes, yes this should work.

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

Re: [yocto] setcap using recipe

2016-06-24 Thread Burton, Ross 
Hi,

On 24 June 2016 at 11:41, Kumar, Shrawan  wrote:

> Is there a way to  add a capability to a binary (cap_net_raw+ep),into a
> recipe?
>
>
>
> Example :
>
> do_install() {
>
>install -d ${D}${bindir}
>
>install -m 0755 helloworld ${D}${bindir}
>
>install -d ${D}/lib/systemd/system
>
>install -m 0755 hello.service ${D}/lib/systemd/system/
>
>setcap cap_net_raw+ep  ${D}${bindir}/helloworld
>
> }
>
>
>
> If yes is this correct approach to achieve the same from  package recipe
> itself ?
>

capabilities on files are just extended attributes, so assuming that you
have a fairly recent Yocto and your host and target filesystems support
extended attributes, yes this should work.

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

[yocto] setcap using recipe

2016-06-24 Thread Kumar, Shrawan 
Hello All,



Is there a way to  add a capability to a binary (cap_net_raw+ep),into a recipe?


Example :

do_install() {

   install -d ${D}${bindir}

   install -m 0755 helloworld ${D}${bindir}

   install -d ${D}/lib/systemd/system

   install -m 0755 hello.service ${D}/lib/systemd/system/

   setcap cap_net_raw+ep  ${D}${bindir}/helloworld

}



If yes is this correct approach to achieve the same from  package recipe itself 
?





Thanks and Regards

Shrawan

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

[yocto] problem with installation pathes of recipes useing cmake + cpack

2016-06-24 Thread S . Jaritz 
Hej

I have several recipes which are based on cmake.  At cmake is the "make 
package" enabled. It is based on CPack(debian).

I am using the predefined GNU installation dirs by 
"include(GNUInstallDirs)" and its variables like CMAKE_INSTALL_FULL_BINDIR 
etc.
(https://cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html)

CMAKE_INSTALL_FULL_BINDIR is set to /usr/local/bin by default, when 
building the package on my development machine outside of Yocto. That is 
fine.

When building the same project in Yocto the CMAKE_INSTALL_FULL_BINDIR is 
set to usr/bin. Seems that the prefix is set by Yocto.

Any ideas how to fix that problem?

Regards

Stefan


ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 176
Telefax: +49 3437 9211 26
E-Mail: s.jar...@esa-grimma.de
Internet: www.esa-grimma.de


Geschäftsführer:
Dipl.-Ing. Jörg Gaitzsch
Jörg Reinker

Sitz der Gesellschaft: Grimma
Ust.-ID: DE 141784437
Amtsgericht: Leipzig, HRB 5159
Steuernummer: 238/108/00755


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
erhalten 
haben, informieren Sie bitte sofort den Absender und löschen Sie diese 
Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser 
Mail 
ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you 
are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is 
strictly 
forbidden.-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Powerpc64e6500 missing altivec option

2016-06-24 Thread Anicic Damir (PSI) 
Hi!

When I built only poky, I had
  TUNE_FEATURES = "m64 fpu-hard e6500 altivec"
and everything was built with -maltivec
and environment-setup-ppc64e6500-poky-linux contained -m altivec:
  export CC="powerpc64-poky-linux-gcc  -mhard-float -m64 -mcpu=e6500 -maltivec 
--sysroot=$SDKTARGETSYSROOT"


It seems that since I added openembedded layers:
/home/anicic/yocto-2.1-all/poky/meta-openembedded/meta-oe \
/home/anicic/yocto-2.1-all/poky/meta-openembedded/meta-python \
/home/anicic/yocto-2.1-all/poky/meta-openembedded/meta-networking \
build reports
  TUNE_FEATURES = "m64 fpu-hard e6500 altivec"
but it builds without altivec,
and environment-setup-ppc64e6500-poky-linux does not have -maltivec any more:
  export CC="powerpc64-poky-linux-gcc  -mhard-float -m64 -mcpu=e6500 
--sysroot=$SDKTARGETSYSROOT"


Where does it get disabled, and how to enable it again?

Damir

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