Re: [meta-intel] [PATCH][V2] common: remove kernel 3.10 and 3.17 bbappend

[Kamble, Nitin A]

Reviewed-By: Nitin A Kamble 

BL, Chin Kooi, Rebecca,
IoTG BSPs are also impacted by removal of the v3.10 kernel from oecore. You 
guys will need to take steps to restore functionality of the IoTG BSPs. If 
needed you can bring the complete v3.10 kernel recipe in the meta-isg layer. 
The other option is to update the kernel version for ISG BSPs.

meta-crystalforest/conf/machine/crystalforest.conf:PREFERRED_VERSION_linux-yocto
 ?= "3.10%"
meta-isg/meta-valleyisland/conf/machine/valleyisland-32.conf:PREFERRED_VERSION_linux-yocto
 ?= "3.10%"
meta-isg/meta-valleyisland/conf/machine/valleyisland-64.conf:PREFERRED_VERSION_linux-yocto
 ?= "3.10%"
meta-isg/meta-mohonpeak/conf/machine/mohonpeak64.conf:PREFERRED_VERSION_linux-yocto
 ?= "3.10%"
meta-isg/meta-mohonpeak/conf/machine/mohonpeak32.conf:PREFERRED_VERSION_linux-yocto
 ?= "3.10%"
meta-isg/meta-haswell-wc/conf/machine/haswell-wc.conf:PREFERRED_VERSION_linux-yocto
 ?= "3.10%"
meta-romley/conf/machine/romley-ivb.conf:PREFERRED_VERSION_linux-yocto ?= 
"3.10%"
meta-romley/conf/machine/romley.conf:PREFERRED_VERSION_linux-yocto ?= "3.10%"


Thanks,
Nitin


> -Original Message-
> From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
> boun...@yoctoproject.org] On Behalf Of Ross Burton
> Sent: Friday, February 20, 2015 12:37 PM
> To: meta-intel@yoctoproject.org
> Subject: [meta-intel] [PATCH][V2] common: remove kernel 3.10 and 3.17
> bbappend
> 
> Kernels 3.10 and 3.17 have been removed from oe-core so remove our
> bbappends.
> 
> Signed-off-by: Ross Burton 
> ---
>  .../linux/linux-yocto-rt_3.10.bbappend |   20 --
>  .../recipes-kernel/linux/linux-yocto_3.10.bbappend |   29 
> 
>  .../recipes-kernel/linux/linux-yocto_3.17.bbappend |   28 ---
>  3 files changed, 77 deletions(-)
>  delete mode 100644 common/recipes-kernel/linux/linux-yocto-
> rt_3.10.bbappend
>  delete mode 100644 common/recipes-kernel/linux/linux-
> yocto_3.10.bbappend
>  delete mode 100644 common/recipes-kernel/linux/linux-
> yocto_3.17.bbappend
> 
> diff --git a/common/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
> b/common/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
> deleted file mode 100644
> index b388122..000
> --- a/common/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> -
> -# For Valley Island
> -KERNEL_FEATURES_INTEL_COMMON = "features/valleyisland-
> io/valleyisland-io.scc"
> -
> -LINUX_VERSION_core2-32-intel-common = "3.10.38"
> -COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
> -SRCREV_meta_core2-32-intel-common =
> "e1f26aeccfd43bc3d7e95873ceda469b631b8473"
> -SRCREV_machine_core2-32-intel-common =
> "8aa9023c5e2e2ca4180e971da9a2c139d5b3c79e"
> -KMACHINE_core2-32-intel-common = "intel-core2-32"
> -KBRANCH_core2-32-intel-common = "standard/preempt-rt/base"
> -KERNEL_FEATURES_append_core2-32-intel-common =
> "${KERNEL_FEATURES_INTEL_COMMON}"
> -
> -LINUX_VERSION_corei7-64-intel-common = "3.10.38"
> -COMPATIBLE_MACHINE_corei7-64-intel-common = "${MACHINE}"
> -SRCREV_meta_corei7-64-intel-common =
> "e1f26aeccfd43bc3d7e95873ceda469b631b8473"
> -SRCREV_machine_corei7-64-intel-common =
> "8aa9023c5e2e2ca4180e971da9a2c139d5b3c79e"
> -KMACHINE_corei7-64-intel-common = "intel-corei7-64"
> -KBRANCH_corei7-64-intel-common = "standard/preempt-rt/base"
> -KERNEL_FEATURES_append_corei7-64-intel-common =
> "${KERNEL_FEATURES_INTEL_COMMON}"
> diff --git a/common/recipes-kernel/linux/linux-yocto_3.10.bbappend
> b/common/recipes-kernel/linux/linux-yocto_3.10.bbappend
> deleted file mode 100644
> index c7989df..000
> --- a/common/recipes-kernel/linux/linux-yocto_3.10.bbappend
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> -
> -# For NUC and Valley Island
> -KERNEL_FEATURES_INTEL_COMMON += "features/amt/mei/mei.scc \
> -  features/valleyisland-io/valleyisland-io.scc"
> -
> -LINUX_VERSION_core2-32-intel-common = "3.10.55"
> -COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
> -SRCREV_meta_core2-32-intel-common =
> "f79a00265eefbe2fffc2cdb03f67235497a9a87e"
> -SRCREV_machine_core2-32-intel-common =
> "3677ea7f9476458aa6dec440243de3a6fb1343a9"
> -KMACHINE_core2-32-intel-common = "intel-core2-32"
> -KBRANCH_core2-32-intel-common = "standard/base"
> -KERNEL_FEATURES_append_core2-32-intel-common =
> "${KERNEL_FEATURES_INTEL_COMMON}"
> -
> -LINUX_VERSION_corei7-64-intel-common = "3.10.55"
> -COMPATIBLE_MACHINE_corei7-64-intel-common = "${MACHINE}"
> -SRCREV_meta_corei7-64-intel-common =
> "f79a00265eefbe2fffc2cdb03f67235497a9a87e"
> -SRCREV_machine_corei7-64-intel-common =
> "3677ea7f9476458aa6dec440243de3a6fb1343a9"
> -KMACHINE_corei7-64-intel-common = "intel-corei7-64"
> -KBRANCH_corei7-64-intel-common = "standard/base"
> -KERNEL_FEATURES_append_corei7-64-intel-common =
> "${KERNEL_FEATURES_INTEL_COMMON}"
> -
> -# For Crystalforest and Romley
> -K

Re: [meta-intel] [PATCH 0/2] libva updates

[Kamble, Nitin A]

Hi Anibal,
  Can you also report what BSPs and what functionality is tested with these 
changes?

Thanks,
Nitin


> -Original Message-
> From: Aníbal Limón [mailto:anibal.li...@linux.intel.com]
> Sent: Friday, February 13, 2015 7:52 AM
> To: meta-intel@yoctoproject.org; Kamble, Nitin A
> Subject: Re: [PATCH 0/2] libva updates
> 
> ping.
> 
> On 10/02/15 09:48, Aníbal Limón wrote:
> > The following changes since commit
> 2acbe8c61bb70406447c9b2085883979fdb1ed43:
> >
> >intel-gpu-tools: Upgrade to 1.9 (2015-01-29 09:16:38 -0600)
> >
> > are available in the git repository at:
> >
> >git://git.yoctoproject.org/meta-intel-contrib alimon/libva_updates
> >http://git.yoctoproject.org/cgit.cgi/meta-intel-
> contrib/log/?h=alimon/libva_updates
> >
> > Aníbal Limón (2):
> >libva: Update to 1.5.0
> >libva-intel-driver: Update to 1.5.0
> >
> >   .../{libva-intel-driver_1.4.1.bb => libva-intel-driver_1.5.0.bb}  | 4 
> > ++--
> >   common/recipes-multimedia/libva/{libva_1.4.1.bb => libva_1.5.0.bb}| 4
> ++--
> >   2 files changed, 4 insertions(+), 4 deletions(-)
> >   rename common/recipes-multimedia/libva/{libva-intel-driver_1.4.1.bb =>
> libva-intel-driver_1.5.0.bb} (88%)
> >   rename common/recipes-multimedia/libva/{libva_1.4.1.bb =>
> libva_1.5.0.bb} (42%)
> >

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

Re: [meta-intel] [PATCH 1/1] valleyisland: update README with latest information

[Kamble, Nitin A]

> -Original Message-
> From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
> boun...@yoctoproject.org] On Behalf Of
> rebecca.swee.fun.ch...@intel.com
> Sent: Tuesday, November 25, 2014 4:51 PM
> To: meta-intel@yoctoproject.org
> Subject: [meta-intel] [PATCH 1/1] valleyisland: update README with latest
> information
> 
> From: Chang Rebecca Swee Fun 
> 
> Added MinnowBoard MAX as one of the supported platform and updated
> the ISG BIOS version information.
> 
> Signed-off-by: Chang Rebecca Swee Fun
> 
Acked-By: Nitin A Kamble 

> ---
>  meta-isg/meta-valleyisland/README | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/meta-isg/meta-valleyisland/README b/meta-isg/meta-
> valleyisland/README
> index 7840acf..073af2a 100644
> --- a/meta-isg/meta-valleyisland/README
> +++ b/meta-isg/meta-valleyisland/README
> @@ -14,6 +14,7 @@ Valley Island BSP is meant to support the following
> platforms:
>  1. Valley Island Development Kit
>  2. Bayley Bay CRB
>  3. Bakersport CRB
> +4. MinnowBoard MAX
> 
>  Further information on the platforms supported by this BSP can be  found
> here:
> @@ -164,14 +165,18 @@ Valley Island Development Kit  BIOS : EBC
> MF01X003  Note : It is recommended to use the default settings of this BIOS
> version.
> 
> -Bayley Bay/ Bakersport CRB
> -BIOS : ISG BIOS 080_021
> -EC   : KSC v3.12
> +Bayley Bay/ Bakersport CRB/ MinnowBoard MAX BIOS : ISG BIOS 092_032
> +EC   : KSC v3.14
> 
>  Required settings in ISG BIOS
> 
> +  OS Selection:
> +Device Manager -> Boot -> OS Selection -> Yocto Linux
> +
>Turn off Secure-boot:
> -Device Manager -> System Setup -> Boot -> Security Boot -> Disable
> +Device Manager -> Secure Boot Configuration -> Attempt Secure Boot ->
> +Uncheck
> 
>Turn off LPE Audio Support:
>  Device Manager -> System Setup -> South Cluster Configuration -> @@ -
> 179,7 +184,7 @@ Required settings in ISG BIOS
> 
>Turn on HD Audio Support:
>  Device Manager -> System Setup -> South Cluster Configuration ->
> -Audio Configuration -> Audio Controller -> Enable
> +Audio Configuration -> Azalia Controller -> Enable
> 
>  Please use EFI mode for all boot medium types, i.e. USB disk and Hard Disk.
>  Setting in BIOS:
> --
> 1.9.1
> 
> --
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 1/1] meta-valleyisland: Update linux-yocto v3.10.43 SRCREV to v3.10.59

[Kamble, Nitin A]

Hi Tom,
  This is a good time to create the dizzy branch in meta-intel. If RC4 becomes 
2.0 release, then this will come after that.

Thanks,
Nitin


> -Original Message-
> From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
> boun...@yoctoproject.org] On Behalf Of wei.tee...@intel.com
> Sent: Tuesday, November 18, 2014 12:07 AM
> To: meta-intel@yoctoproject.org
> Subject: [meta-intel] [PATCH 1/1] meta-valleyisland: Update linux-yocto
> v3.10.43 SRCREV to v3.10.59
> 
> From: "Ng, Wei Tee" 
> 
> Use the latest HEADs of the git branches from the linux-yocto
> v3.10 kernel repository
> 
> Signed-off-by: Ng, Wei Tee 
> ---
>  .../recipes-kernel/linux/linux-yocto_3.10.bbappend |   12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-
> yocto_3.10.bbappend b/meta-isg/meta-valleyisland/recipes-
> kernel/linux/linux-yocto_3.10.bbappend
> index dbc01a5..4da8a19 100644
> --- a/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-
> yocto_3.10.bbappend
> +++ b/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-
> yocto_3.10.bbappend
> @@ -9,9 +9,9 @@ KBRANCH_valleyisland-32 = "standard/base"
>  KERNEL_FEATURES_valleyisland-32 = " features/valleyisland-io/valleyisland-
> io.scc \
>   features/valleyisland-io/valleyisland-io-
> pci.scc"
> 
> -LINUX_VERSION_valleyisland-32 = "3.10.43"
> -SRCREV_machine_valleyisland-32 =
> "e4f08d724d6663e6d23d19668c97f9e6792c94d2"
> -SRCREV_meta_valleyisland-32 =
> "fab23a4d44de25ee77e497cbf8605eadc3aaf3d8"
> +LINUX_VERSION_valleyisland-32 = "3.10.59"
> +SRCREV_machine_valleyisland-32 =
> "747e1cbd12b15db8bc2ae86e2359c1b113f120d6"
> +SRCREV_meta_valleyisland-32 =
> "8f05306a8e6f5ee422d50c3317acce0cf9e6aada"
>  SRCREV_valleyisland-io_valleyisland-32 =
> "0992d01f5f382f6da60004ef87f67ebd3ca13732"
> 
>  SRC_URI_valleyisland-32 = "git://git.yoctoproject.org/linux-yocto-
> 3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisla
> nd-io-3.0;name=machine,meta,valleyisland-io"
> @@ -25,9 +25,9 @@ KBRANCH_valleyisland-64 = "standard/base"
>  KERNEL_FEATURES_valleyisland-64 = " features/valleyisland-io/valleyisland-
> io.scc \
>   features/valleyisland-io/valleyisland-io-
> pci.scc"
> 
> -LINUX_VERSION_valleyisland-64 = "3.10.43"
> -SRCREV_machine_valleyisland-64 =
> "e4f08d724d6663e6d23d19668c97f9e6792c94d2"
> -SRCREV_meta_valleyisland-64 =
> "fab23a4d44de25ee77e497cbf8605eadc3aaf3d8"
> +LINUX_VERSION_valleyisland-64 = "3.10.59"
> +SRCREV_machine_valleyisland-64 =
> "747e1cbd12b15db8bc2ae86e2359c1b113f120d6"
> +SRCREV_meta_valleyisland-64 =
> "8f05306a8e6f5ee422d50c3317acce0cf9e6aada"
>  SRCREV_valleyisland-io_valleyisland-64 =
> "0992d01f5f382f6da60004ef87f67ebd3ca13732"
> 
>  SRC_URI_valleyisland-64 = "git://git.yoctoproject.org/linux-yocto-
> 3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisla
> nd-io-3.0;name=machine,meta,valleyisland-io"
> --
> 1.7.9.5
> 
> --
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] DPDK failing in git master

[Kamble, Nitin A]

Hi Sreeju, BL,
  We are about to release meta-intel 2.0 release. And we would not like to 
release with a failing recipe like this. Can we get some quick turnaround on 
this issue?

Thanks,
Nitin


From: meta-intel-boun...@yoctoproject.org 
[mailto:meta-intel-boun...@yoctoproject.org] On Behalf Of Burton, Ross
Sent: Wednesday, November 05, 2014 4:00 PM
To: Selvaraj, Sreeju ArmughanX; meta-intel@yoctoproject.org
Subject: [meta-intel] DPDK failing in git master

Hi,

Since we've upgraded the kernel to 3.17, DPDK fails to build:

dpdk-1.7.0/x86_64-ivshmem-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/kni_misc.c:348:20:
 error: macro "alloc_netdev" requires 4 arguments, but only 3 given
(and more)

alloc_netdev() gained a name_assign_type argument in 3.17.

Ross


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

Re: [meta-intel] [PATCH 1/1] meta-emenlow: Update linux-yocto_3.17 SRCREVs to v3.17.1

[Kamble, Nitin A]

> -Original Message-
> From: Zanussi, Tom
> Sent: Tuesday, November 04, 2014 1:45 PM
> To: Kamble, Nitin A
> Cc: dvh...@linux.intel.com; meta-intel@yoctoproject.org
> Subject: Re: [PATCH 1/1] meta-emenlow: Update linux-yocto_3.17 SRCREVs
> to v3.17.1
> 
> 
> On Tue, 2014-11-04 at 13:38 -0800, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > Use the latest HEADs of the git branches from the linux-yocto v3.17
> > kernel repository.
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  common/recipes-kernel/linux/linux-yocto_3.17.bbappend | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/common/recipes-kernel/linux/linux-yocto_3.17.bbappend
> > b/common/recipes-kernel/linux/linux-yocto_3.17.bbappend
> 
> This is meta-emenlow?


This is not meta-emenlow, it is the common kernel recipe. And it covers emenlow 
BSP as well.
I fixed the typo in the commit message on the contrib branch.

Nitin

> 
> > index 72cff48..dcb0740 100644
> > --- a/common/recipes-kernel/linux/linux-yocto_3.17.bbappend
> > +++ b/common/recipes-kernel/linux/linux-yocto_3.17.bbappend
> > @@ -5,7 +5,7 @@ KERNEL_FEATURES_INTEL_COMMON +=
> "features/amt/mei/mei.scc"
> >
> >  LINUX_VERSION_core2-32-intel-common = "3.17.1"
> >  COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
> > -SRCREV_meta_core2-32-intel-common =
> "229ce533868773f201f9ab36e2b4248b381309ec"
> > +SRCREV_meta_core2-32-intel-common =
> "b86dd5c6f4d87cc4d8097ab8ffa445ef6d4b4ccf"
> >  SRCREV_machine_core2-32-intel-common =
> "0caf16d38536e3dec8a02ea657e1960f1216f174"
> >  KMACHINE_core2-32-intel-common = "intel-core2-32"
> >  KBRANCH_core2-32-intel-common = "standard/base"
> > @@ -13,7 +13,7 @@ KERNEL_FEATURES_append_core2-32-intel-common
> = "${KERNEL_FEATURES_INTEL_COMMON}"
> >
> >  LINUX_VERSION_corei7-64-intel-common = "3.17.1"
> >  COMPATIBLE_MACHINE_corei7-64-intel-common = "${MACHINE}"
> > -SRCREV_meta_corei7-64-intel-common =
> "229ce533868773f201f9ab36e2b4248b381309ec"
> > +SRCREV_meta_corei7-64-intel-common =
> "b86dd5c6f4d87cc4d8097ab8ffa445ef6d4b4ccf"
> >  SRCREV_machine_corei7-64-intel-common =
> "0caf16d38536e3dec8a02ea657e1960f1216f174"
> >  KMACHINE_corei7-64-intel-common = "intel-corei7-64"
> >  KBRANCH_corei7-64-intel-common = "standard/base"
> 

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

Re: [meta-intel] failed to build DPDK v1.7.0

[Kamble, Nitin A]

Hi BL,

Are there different variants of DPDK for different platforms? The DPDK recipe 
in the meta-intel layer is in common directory, means it is available for all 
the BSPs. Won’t it work with all the BSPs? If it is specific to a particular 
BSP such as romley, then it should go in the meta-romley directory instead of 
the common dir.

Nitin


From: , Boon Ong 
mailto:boon.leong@intel.com>>
Date: Tuesday, October 28, 2014 at 6:57 PM
To: Lai Eddy mailto:eddy.lai...@gmail.com>>
Cc: "meta-intel@yoctoproject.org" 
mailto:meta-intel@yoctoproject.org>>, "Schuetze, 
Joel D" mailto:joel.d.schue...@intel.com>>, "Khade, 
Abhishek" mailto:abhishek.kh...@intel.com>>
Subject: Re: [meta-intel] failed to build DPDK v1.7.0

Hi Eddy,
The DPD v1.7 recipe that was contributed is validated with 
meta-romley. Do note that DPDK comes with dependency on the network driver.
So far, we have no seen any request on enabling DPDK v1.7 on 
Mohonpeak.
CC’ed Joel and Abhishek who may be able to guide you on the 
right DPDK version to use for Mohonpeak.

Thanks
Boon Leong

From: 
meta-intel-boun...@yoctoproject.org 
[mailto:meta-intel-boun...@yoctoproject.org] On Behalf Of Lai Eddy
Sent: Monday, October 20, 2014 9:55 PM
To: Selvaraj, Sreeju ArmughanX
Cc: meta-intel@yoctoproject.org
Subject: [meta-intel] failed to build DPDK v1.7.0

yocto 1.6.1 on Ubuntu 12.04 , mohonpeak BSP
build dpdk got following errors:
=
ERROR: Function failed: do_compile (log file is located at 
/c2000/tmp/work/mohonpeak64-poky-linux/dpdk/1.7.0-r0/temp/log.do_compile.10103)
ERROR: Logfile of failure stored in: 
/c2000/tmp/work/mohonpeak64-poky-linux/dpdk/1.7.0-r0/temp/log.do_compile.10103
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 4 -e MAKEFLAGS= EXTRA_LDFLAGS= 
--sysroot=/c2000/tmp/sysroots/mohonpeak64 EXTRA_CFLAGS= 
--sysroot=/c2000/tmp/sysroots/mohonpeak64 CROSS=x86_64-poky-linux- prefix= 
LDFLAGS= WERROR_FLAGS=-w V=1
| make[1]: Entering directory 
`/c2000/tmp/work/mohonpeak64-poky-linux/dpdk/1.7.0-r0/dpdk-1.7.0'
| == Build scripts
| == Build scripts/testhost
| == Build lib
| == Build lib/librte_eal
| == Build lib/librte_eal/common
| == Build lib/librte_eal/linuxapp
| == Build lib/librte_eal/linuxapp/igb_uio
|   Building modules, stage 2.
|   MODPOST 1 modules
| == Build lib/librte_eal/linuxapp/eal
| == Build lib/librte_eal/linuxapp/kni
|   Building modules, stage 2.
|   MODPOST 1 modules
| == Build lib/librte_malloc
| == Build lib/librte_ring
| == Build lib/librte_mempool
| == Build lib/librte_mbuf
| == Build lib/librte_timer
| == Build lib/librte_cfgfile
| == Build lib/librte_cmdline
| == Build lib/librte_ether
| == Build lib/librte_net
| == Build lib/librte_pmd_e1000
| == Build lib/librte_pmd_ixgbe
| x86_64-poky-linux-gcc -Wp,-MD,./.ixgbe_rxtx_vec.o.d.tmp -m64 -pthread  
-march=native -DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2 
-DRTE_MACHINE_CPUFLAG_SSE3 -DRTE_MACHINE_CPUFLAG_SSSE3 
-DRTE_COMPILE_TIME_CPUFLAGS=RTE_CPUFLAG_SSE,RTE_CPUFLAG_SSE2,RTE_CPUFLAG_SSE3,RTE_CPUFLAG_SSSE3
  -O2 -pipe -g -feliminate-unused-debug-types 
-I/c2000/tmp/work/mohonpeak64-poky-linux/dpdk/1.7.0-r0/dpdk-1.7.0/x86_64-ivshmem-linuxapp-gcc/include
 -include 
/c2000/tmp/work/mohonpeak64-poky-linux/dpdk/1.7.0-r0/dpdk-1.7.0/x86_64-ivshmem-linuxapp-gcc/include/rte_config.h
 -O3 -W -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes 
-Wmissing-declarations -Wold-style-definition -Wpointer-arith -Wcast-align 
-Wnested-externs -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef 
-Wwrite-strings -Wno-deprecated  
--sysroot=/media/datahd/c2000/tmp/sysroots/mohonpeak64 -o ixgbe_rxtx_vec.o -c 
/c2000/tmp/work/mohonpeak64-poky-linux/dpdk/1.7.0-r0/dpdk-1.7.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
| In file included from 
/c2000/tmp/work/mohonpeak64-poky-linux/dpdk/1.7.0-r0/dpdk-1.7.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:41:0:
| 
/c2000/tmp/sysroots/x86_64-linux/usr/lib/corei7-64-poky-linux/gcc/x86_64-poky-linux/4.8.2/include/nmmintrin.h:31:3:
 error: #error "SSE4.2 instruction set not enabled"
|  # error "SSE4.2 instruction set not enabled"
|^
| 
/c2000/tmp/work/mohonpeak64-poky-linux/dpdk/1.7.0-r0/dpdk-1.7.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:
 In function 'ixgbe_recv_pkts_vec':
| 
/c2000/tmp/work/mohonpeak64-poky-linux/dpdk/1.7.0-r0/dpdk-1.7.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:297:3:
 error: implicit declaration of function '_mm_shuffle_epi8' 
[-Werror=implicit-function-declaration]
|pkt_mb4 = _mm_shuffle_epi8(descs[3], shuf_msk);
|^
:
:
:
| 
/c2000/tmp/work/mohonpeak64-poky-linux/dpdk/1.7.0-r0/dpdk-1.7.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:341:3:
 error: implicit declaration of function '_mm_popcnt_u64' 
[-Werror=implicit-function-declaration]
|var = _mm_popcnt_u64(_mm_cvtsi128_si6

Re: [meta-intel] Problem with GIT

[Kamble, Nitin A]

These URLs should work.
git://git.yoctoproject.org/linux-yocto-3.10
http://git.yoctoproject.org/git/linux-yocto-3.10


If you are behind a firewall check your proxy settings.

Nitin


On 10/28/14, 9:59 AM, "Brian Dahl"  wrote:

>Hi,
>i want to clone the git repo git://git.yoctoproject.org/linux-yocto-3.10
>but I receive fatal: Not a git repository (or any of the parent
>directories) Is the server down or a new url
>
>Thx
>
>Brian
>--
>
>Dahl-IT
>Ihr Partner in Fragen IT und Telekommunikation
>Brian Dahl Software-,
>Hardwareentwicklung,
>PC Technik und Telefonanlagen.
>
>Karlstr. 35
>80333 München
>
>e-Mail: b...@dahl-it.de
>Telefon: +49 (0)89 416107020
>Telefax: +49 (0)89 416107029
>
>HINWEIS: Dies ist eine vertrauliche Nachricht und nur für den Adressaten
>bestimmt. Es ist nicht erlaubt, diese Nachricht zu kopieren oder Dritten
>zugänglich zu machen. Sollten Sie diese Nachricht irrtümlich erhalten
>haben, bitte ich um Ihre Mitteilung per E-Mail oder unter der oben
>angegebenen Telefonnummer.
>-- 
>___
>meta-intel mailing list
>meta-intel@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/meta-intel

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

Re: [meta-intel] Core-i7 support

[Kamble, Nitin A]

Teemu,
  
conf/machine/intel-corei7-64.conf was introduced in the Daisy release. You
won¹t find it in the Dora release. And I think you are getting confused by
the the BSP name here. intel-corei7-64.conf is a BSP to generically
support most of the Intel core base 64bit machines. There are also other
machine specific BSPs such as nuc or sugarbay. I am not clear what are you
looking for? If you want the generic intel-corei7-64 BSP, then you will
have to move forward to at least daisy. If you just want support for Intel
core i7 processors in the dora branch, then you can look at the nuc or
sugarbay BSPs, or write with your own BSP.

Nitin

On 10/26/14, 9:21 PM, "Keskinarkaus, Teemu"
 wrote:

>Well, yes I know that. That's why I specifically said that I downloaded
>for Dora because that's the branch we are using. Does that mean that Core
>i7 support is removed from Dora-branch?
>
>Teemu Keskinarkaus
>
>> -Original Message-
>> From: Kamble, Nitin A [mailto:nitin.a.kam...@intel.com]
>> Sent: 24. lokakuuta 2014 20:23
>> To: Keskinarkaus, Teemu; meta-intel@yoctoproject.org
>> Subject: Re: [meta-intel] Core-i7 support
>>
>> The latest release is Daisy not Dora. And within few weeks Dizzy will
>>be latest
>> release.
>>
>> The latest Daisy BSP for corei7 is here.
>> https://www.yoctoproject.org/downloads/bsps/daisy161/intel-corei7-64
>>
>> And in few weeks there will be a new latest available for the BSP.
>>
>> Nitin
>>
>> From: , Teemu
>> mailto:Teemu.Keskinarkaus@Maxima
>> tecc.com>>
>> Date: Thursday, October 23, 2014 at 10:08 PM
>> To: "meta-intel@yoctoproject.org<mailto:meta-intel@yoctoproject.org>"
>> mailto:meta-intel@yoctoproject.org>>
>> Subject: [meta-intel] Core-i7 support
>>
>> Hi,
>>
>> It's been few months that I last time tried core i7 in Yocto. Now I
>>downloaded
>> latest meta-intel for dora and noticed that
>>conf/machine/intel-corei7-64.conf is
>> gone. I guess the core-i7 support is moved somewhere, but where? Only
>> reference to i7 I could find was in Sugarbay so should I use that or
>>what I should
>> use?
>>
>> Teemu Keskinarkaus
>>
>>
>>
>> 
>>
>> Actuant Corporation Email Notice
>>
>> This message is intended only for the use of the Addressee and may
>>contain
>> information that is PRIVILEGED and/or CONFIDENTIAL.
>> This email is intended only for the personal and confidential use of
>>the recipient(s)
>> named above. If the reader of this email is not an intended recipient,
>>you have
>> received this email in error and any review, dissemination,
>>distribution or copying
>> is strictly prohibited.
>> If you have received this email in error, please notify the sender
>>immediately by
>> return mail and permanently delete the copy you received.
>>
>> Thank you.
>
>
>
>Actuant Corporation Email Notice
>
>This message is intended only for the use of the Addressee and may
>contain information that is PRIVILEGED and/or CONFIDENTIAL.
>This email is intended only for the personal and confidential use of the
>recipient(s) named above. If the reader of this email is not an intended
>recipient, you have received this email in error and any review,
>dissemination, distribution or copying is strictly prohibited.
>If you have received this email in error, please notify the sender
>immediately by return mail and permanently delete the copy you received.
>
>Thank you.

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

Re: [meta-intel] Core-i7 support

[Kamble, Nitin A]

The latest release is Daisy not Dora. And within few weeks Dizzy will be latest 
release.

The latest Daisy BSP for corei7 is here. 
https://www.yoctoproject.org/downloads/bsps/daisy161/intel-corei7-64

And in few weeks there will be a new latest available for the BSP.

Nitin

From: , Teemu 
mailto:teemu.keskinark...@maximatecc.com>>
Date: Thursday, October 23, 2014 at 10:08 PM
To: "meta-intel@yoctoproject.org" 
mailto:meta-intel@yoctoproject.org>>
Subject: [meta-intel] Core-i7 support

Hi,

It’s been few months that I last time tried core i7 in Yocto. Now I downloaded 
latest meta-intel for dora and noticed that conf/machine/intel-corei7-64.conf 
is gone. I guess the core-i7 support is moved somewhere, but where? Only 
reference to i7 I could find was in Sugarbay so should I use that or what I 
should use?

Teemu Keskinarkaus





Actuant Corporation Email Notice

This message is intended only for the use of the Addressee and may contain 
information that is PRIVILEGED and/or CONFIDENTIAL.
This email is intended only for the personal and confidential use of the 
recipient(s) named above. If the reader of this email is not an intended 
recipient, you have received this email in error and any review, dissemination, 
distribution or copying is strictly prohibited.
If you have received this email in error, please notify the sender immediately 
by return mail and permanently delete the copy you received.

Thank you.
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [Patch v4 04/12] README: Documentation of hardware features

[Kamble, Nitin A]

On 10/21/14, 9:02 AM, "Zanussi, Tom"  wrote:

>On Thu, 2014-10-16 at 19:03 -0700, nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> Starting a new documentation section to describe the layer specific
>>hardware
>> features. At this point the intel-ucode machine feature is described
>>here.
>> In the future more such features will be described in this section.
>> 
>> Signed-off-by: Nitin A Kamble 
>
>I went through and made a bunch of changes to this, nothing substantive,
>but rather than enumerating every change in-line, I'm just posting the
>diff.
>
>Please review and see if it looks ok.

Looks ok mostly, some specific changes suggested below.

Thanks,
Nitin

>
>Tom
>
> diff --git a/README b/README
>index 5b8217d..60811b1 100644
>--- a/README
>+++ b/README
>@@ -85,93 +85,113 @@ larger and/or more involved patches and patchsets,
>the review process
> may take longer.
> 
> 
>-Machine Features in the meta-intel layer
>-
>+Intel-specific machine features
>+===
> 
>-Many machine features are available in the oecore/poky layer for BSP use.
>-The meta-intel layer makes some additional machine features available to
>BSPs
>-using the meta-intel layer.
>+The meta-intel layer makes some additional machine features available
>+to BSPs.  These machine features can be used in a BSP layer in the
>+same way that machine features are used in other layers based on
>+oe-core, via the MACHINE_FEATURES variable.
> 
> Requirements
> 
> 
>-The additional machine features are only available when the meta-intel
>layer
>-is included in the build config, and the meta-intel.inc file is included
>in
>-the machine configuration of the interested BSP.
>+The meta-intel-specific machine features are only available to a BSP
>+when the meta-intel layer is included in the build configuration, and
>+the meta-intel.inc file is included in the machine configuration of
>+that BSP.
> 
> To make these features available for your machine, you will need to:
> 
>-1. have a configuration line as seen below in the bblayers.conf
>+  1. include a configuration line such as the below in bblayers.conf
>   BBLAYERS += "/meta-intel"
>-2. have the following line in the machine configuration
>+  2. include the following line in the machine configuration file
>   require conf/machine/include/meta-intel.inc
> 
>-Once the above requirements are met, then the machine features provided
>by
>+Once the above requirements are met, the machine features provided by
> the meta-intel layer will be available for the BSP to use.
> 
>-Available Machine Features
>+Available machine features
> --
> 
>-As of now the meta-intel layer provides the following list of machine
>features.
>-In the future, more machine features may be available in this list.
>+Currently, the meta-intel layer makes the following set of
>+Intel-specific machine features available:
> 
>-* intel-ucode
>+  * intel-ucode
>+
>+These machine features can be included by listing them in the
>+MACHINE_FEATURES variable in the machine configuration file.  For
>+example:
> 
>-These machine features can be included by listing them in the
>MACHINE_FEATURES
>-variable in the machine configuration file.
>-For example:
>   MACHINE_FEATURES += "intel-ucode"
> 
>-Details of the Machine Features
>
>-
>-* intel-ucode: This feature provides microcode updating support for Intel
>-  processors. This feature runs at early boot and uses the microcode data
>-  file from initrd. It also puts the user land microcode updating tool
>-  iucode_tool and the microcode data file in the target images.
>-
>-  Q. Why enable this microcode feature?
>-  A. Intel releases microcode updates to correct processor behavior as
>- documented in the respective processor specification updates. While
>- the regular approach to getting this microcode update is via a BIOS
>- upgrade, this can be an administrative hassle and not always
>possible
>- in the field. The intel-ucode feature enables the microcode update
>- capability from the Linux OS. It provides an easy path for upgrading
>- processor microcode without the need to change BIOS. Once the
>feature
>- is enabled, it is also possible to update the existing images with
>- a newer microcode update in the future.
>-
>-  Q. How to bundle only specific microcode in the target image?
>-  A. The Intel microcode data file released by Intel contains microcode
>- updates for multiple processors. If the BSP image will be running
>only
>- on a certain kind of processors, then the number of microcode
>bundled in
>- the target image can be filtered by specifying the
>UCODE_FILTER_PARAMETERS
>- variable. A sequence of iucode-tool parameters are listed in the
>- UCODE_FILTER_PARAMETERS variable to filter the microcodes from the
>- microcode data file. For more information on these parameters refe

Re: [meta-intel] [Patch v2 00/11] machinesetuptool commits

[Kamble, Nitin A]

On 10/10/14, 2:18 PM, "Darren Hart"  wrote:

>On 10/10/14, 11:46, "Kamble, Nitin A"  wrote:
>
>>
>>On 10/10/14, 9:40 AM, "Darren Hart"  wrote:
>>
>>>
>>>Another concern is the statement below about not allowing for a default
>>>configuration. Like other recent changes to meta-intel, this should be
>>>an
>>>opt-in thing, and as such, the BSPs need to be able to provide defaults.
>>>The intel-corei7-64 BSP works well as it is for a number of Intel
>>>platforms, and people using those may prefer not to use the
>>>machinesetuptool.
>>
>>As mentioned earlier, it was needed for the reconfiguration of images.
>>The
>>target machine which is configured as a default target machine can be
>>used
>>for this purpose. Which makes the tool transparent to them. So I am not
>>seeing any significant issue here. I think ability to reconfigure an
>>image
>>is a great benefit for development and testing.
>
>The primary issue with eliminating the defaults from intel-corei7-64 and
>providing the default via machinesetuptool, is we then make
>machinesetuptool a requirement for that BSP for basic functionality. That
>isn't acceptable in my opinion.

So what is the proposal? Disable machinesetuptool by default, and enable
it if you need it?
 
Nitin

>
>-- 
>Darren Hart
>Intel Open Source Technology Center
>
>
>

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

Re: [meta-intel] [PATCH 1/3] crownbay-noemgd: disable the gma500_gfx module

[Kamble, Nitin A]

On 10/10/14, 1:34 PM, "Darren Hart"  wrote:

>On 10/10/14, 10:46, "Kamble, Nitin A"  wrote:
>
>>
>>
>>On 10/10/14, 10:31 AM, "Zanussi, Tom"  wrote:
>>
>>>On Fri, 2014-10-10 at 12:25 -0500, Kamble, Nitin A wrote:
>>>> 
>>>> On 10/10/14, 6:37 AM, "Zanussi, Tom"  wrote:
>>>> 
>>>> >On Thu, 2014-10-09 at 15:11 -0700, nitin.a.kam...@intel.com wrote:
>>>> >> From: Nitin A Kamble 
>>>> >> 
>>>> >> The gmx500 graphics driver does not work on this BSP, but it takes
>>>> >> the ownership of the graphics hardware at boot time, blocking other
>>>> >> drivers from using the graphics hardware.
>>>> >> 
>>>> >> Fix the issue by blacklisting the gma500_gfx kernel module in the
>>>>kmod
>>>> >> configuration, so that it doesn't get loaded at boot time.
>
>Does gma500 work anywhere? If not, perhaps it doesn't belong in the
>intel-common BSPs. I really wanted it to be a reasonable fallback to EMGD,
>but it just doesn't seem to work anywhere.

It does work on and needed for the emenlow-noemgd BSP.

Nitin


>
>--
>Darren
>
>>>> >> 
>>>> >
>>>> >Is this really the right way to do this?  It will only work if
>>>> >CONFIG_XXX=m.  If m->y at some point, the whole .bbappend becomes
>>>> >useless at best.
>>>> 
>>>> That is why the gma500 is converted from y to m. And with the common
>>>> kernel,
>>>> It should be m anyway. If you have better way to solve you can share.
>>>> 
>>>
>>>Why not a config fragment that turns it off for that BSP?
>>>
>>>The more general question is whether the common kernel mandates
>>>everything be 'm' for this reason.
>>>
>>>Tom
>>
>>This will be going backwards. We are trying to consolidate kernel and
>>BSPs. 
>>And this suggested approach will make a separate kernel for this BSP.
>>
>>The common kernel has lot of drivers enabled. And very few of them will
>>be
>>actually used on any particular BSP. Not using kernel modules for these
>>many
>>drivers will be insane.
>>
>>Nitin
>>
>>
>>>
>>>> Nitin
>>>> 
>>>> 
>>>> >
>>>> >Tom
>>>> >
>>>> >> Fixes Bug:
>>>> >> [YOCTO #6807]
>>>> >> 
>>>> >> Signed-off-by: Nitin A Kamble 
>>>> >> ---
>>>> >>  meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend | 3 +++
>>>> >>  1 file changed, 3 insertions(+)
>>>> >>  create mode 100644
>>>>meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
>>>> >> 
>>>> >> diff --git a/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
>>>> >>b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
>>>> >> new file mode 100644
>>>> >> index 000..56d8fcb
>>>> >> --- /dev/null
>>>> >> +++ b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
>>>> >> @@ -0,0 +1,3 @@
>>>> >> +do_install_append () {
>>>> >> +   echo "blacklist gma500_gfx" >
>>>> >>${D}${sysconfdir}/modprobe.d/prohibit_gma500_gfx.conf
>>>> >> +}
>>>> >
>>>> >
>>>> 
>>>
>>>
>>
>>
>
>
>-- 
>Darren Hart
>Intel Open Source Technology Center
>
>
>

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

Re: [meta-intel] [Patch v2 00/11] machinesetuptool commits

[Kamble, Nitin A]

On 10/10/14, 9:40 AM, "Darren Hart"  wrote:

>Hi Nitin,
>
>This description helps to identify _what_ the tool is intended to do, but
>it still does not address the _how_, which is important context to have
>when reviewing the patches. There was also no mention of the sources to
>the tool itself, also important for context.

Location of the machine setup tool sources:
http://git.yoctoproject.org/cgit/cgit.cgi/machinesetuptool/


How a target machine is configured?
A. An initscript for the tool is ran on every boot, which checks weather a
valid target machine is already set. If the machine is already set, then
it means that the images is already configured for the target machine, and
nothing much need to be done for setting up, except running any machine
specific Boot time scripts. If the image is not previously setup, which is
the case for the 1st time boot of the image, then the machine detection
script is run, which is not implemented at this point. If the target
machine is not successfully detected, then the target machine selection
script is run, which provides a boot prompt along with list of supported
target machine. The boot prompt comes before the boot splash screen, so it
don¹t get hidden. End user can interactively enter the name of target
machine at the boot prompt. If no input is received on the the boot
prompt, then after timeout of 1 minute, the target machine which is marked
as default machine in the configuration is chosen. Once the target machine
is chosen, then the .vars file is used to find all the
configuration for the machine. Few machine configuration are listed in the
commits. And look at setup.in file in the sources to see how the machine
configuration is handled.



>
>One gap below is Gummiboot serial support, which I had intended to switch
>meta-intel EFI support over too this release (looking like that may not
>happen... Will look into how invasive that would be).

It can be specified as addition configuration.

>
>Another concern is the statement below about not allowing for a default
>configuration. Like other recent changes to meta-intel, this should be an
>opt-in thing, and as such, the BSPs need to be able to provide defaults.
>The intel-corei7-64 BSP works well as it is for a number of Intel
>platforms, and people using those may prefer not to use the
>machinesetuptool.

As mentioned earlier, it was needed for the reconfiguration of images. The
target machine which is configured as a default target machine can be used
for this purpose. Which makes the tool transparent to them. So I am not
seeing any significant issue here. I think ability to reconfigure an image
is a great benefit for development and testing.

Thanks for the comments Darren,
Nitin




>
>--
>Darren
>
>On 10/8/14, 5:32, "nitin.a.kam...@intel.com" 
>wrote:
>
>>From: Nitin A Kamble 
>>
>>As this is totally new feature I am including some explanation as a
>>simple
>>design document for ease of understanding the implementation.
>>
>>Machine Setup Tool
>>
>>Q. Why is this feature implemented?
>>A. Many of the BSPs from meta-intel are very similar differing only in
>>the
>>   configuration of things such as serial port, X configuration, network,
>>   audio, kernel parameters etc. Now with the common kernel it is
>>possible
>>   to support more platforms or boards with a single BSP. The only thing
>>   missing was the text configuration customization for a particular
>>hardware
>>   platform. The machine setup tool fills this gap.
>>
>>Q. What the machine setup tool can do?
>>A. It provides following capabilities:
>>   * Provide previously defined machine configurations.
>>   * Ability to select a target machine at runtime at the time of boot.
>>   * Ability to reconfigure a previously configured machine for another
>>supported platform.
>>   * Ability to select a default machine when no user input is received
>>at the boot time.
>>   * These configurations can be specified for machines
>> * ALSA audio configuration file
>> * ALSA Mixer state file
>> * Network configuration file
>> * xorg configuration file
>> * Machine formfactor file
>> * Kernel boot parameters
>> * A list of blacklisted kernel modules
>> * A list of kernel modules to autoload
>> * Serial port configuration for syslinux boot loader
>> * Serial port configuration for grub boot loader
>> * Serial port configuration for setting up serial console
>> * Any scripts to run at setup time
>> * Any scripts to run on every boot
>>
>>Q. What the machine setup tool can not do?
>>A. Anything, which can not be easily manipulated on the target image is
>>   outside of the scope of the machine setup tool. So things like
>>providing
>>   a custom kernel, or providing any special binaries is outside the
>>scope
>>   of the machine setup tool.
>>
>>Q. Is the machine setup tool arch specific?
>>A. Even though, the tool is mainly designed for the BSPs from the
>>meta-intel
>>   layer, there is no architecture speci

Re: [meta-intel] [PATCH 1/3] crownbay-noemgd: disable the gma500_gfx module

[Kamble, Nitin A]

On 10/10/14, 10:31 AM, "Zanussi, Tom"  wrote:

>On Fri, 2014-10-10 at 12:25 -0500, Kamble, Nitin A wrote:
>> 
>> On 10/10/14, 6:37 AM, "Zanussi, Tom"  wrote:
>> 
>> >On Thu, 2014-10-09 at 15:11 -0700, nitin.a.kam...@intel.com wrote:
>> >> From: Nitin A Kamble 
>> >> 
>> >> The gmx500 graphics driver does not work on this BSP, but it takes
>> >> the ownership of the graphics hardware at boot time, blocking other
>> >> drivers from using the graphics hardware.
>> >> 
>> >> Fix the issue by blacklisting the gma500_gfx kernel module in the
>>kmod
>> >> configuration, so that it doesn't get loaded at boot time.
>> >> 
>> >
>> >Is this really the right way to do this?  It will only work if
>> >CONFIG_XXX=m.  If m->y at some point, the whole .bbappend becomes
>> >useless at best.
>> 
>> That is why the gma500 is converted from y to m. And with the common
>> kernel,
>> It should be m anyway. If you have better way to solve you can share.
>> 
>
>Why not a config fragment that turns it off for that BSP?
>
>The more general question is whether the common kernel mandates
>everything be 'm' for this reason.
>
>Tom

This will be going backwards. We are trying to consolidate kernel and
BSPs. 
And this suggested approach will make a separate kernel for this BSP.

The common kernel has lot of drivers enabled. And very few of them will be
actually used on any particular BSP. Not using kernel modules for these
many
drivers will be insane.

Nitin


>
>> Nitin
>> 
>> 
>> >
>> >Tom
>> >
>> >> Fixes Bug:
>> >> [YOCTO #6807]
>> >> 
>> >> Signed-off-by: Nitin A Kamble 
>> >> ---
>> >>  meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend | 3 +++
>> >>  1 file changed, 3 insertions(+)
>> >>  create mode 100644
>>meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
>> >> 
>> >> diff --git a/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
>> >>b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
>> >> new file mode 100644
>> >> index 000..56d8fcb
>> >> --- /dev/null
>> >> +++ b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
>> >> @@ -0,0 +1,3 @@
>> >> +do_install_append () {
>> >> + echo "blacklist gma500_gfx" >
>> >>${D}${sysconfdir}/modprobe.d/prohibit_gma500_gfx.conf
>> >> +}
>> >
>> >
>> 
>
>

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

Re: [meta-intel] [PATCH 1/3] crownbay-noemgd: disable the gma500_gfx module

[Kamble, Nitin A]

On 10/10/14, 6:37 AM, "Zanussi, Tom"  wrote:

>On Thu, 2014-10-09 at 15:11 -0700, nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> The gmx500 graphics driver does not work on this BSP, but it takes
>> the ownership of the graphics hardware at boot time, blocking other
>> drivers from using the graphics hardware.
>> 
>> Fix the issue by blacklisting the gma500_gfx kernel module in the kmod
>> configuration, so that it doesn't get loaded at boot time.
>> 
>
>Is this really the right way to do this?  It will only work if
>CONFIG_XXX=m.  If m->y at some point, the whole .bbappend becomes
>useless at best.

That is why the gma500 is converted from y to m. And with the common
kernel,
It should be m anyway. If you have better way to solve you can share.

Nitin


>
>Tom
>
>> Fixes Bug:
>> [YOCTO #6807]
>> 
>> Signed-off-by: Nitin A Kamble 
>> ---
>>  meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend | 3 +++
>>  1 file changed, 3 insertions(+)
>>  create mode 100644 meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
>> 
>> diff --git a/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
>>b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
>> new file mode 100644
>> index 000..56d8fcb
>> --- /dev/null
>> +++ b/meta-crownbay/recipes-kernel/kmod/kmod_git.bbappend
>> @@ -0,0 +1,3 @@
>> +do_install_append () {
>> +echo "blacklist gma500_gfx" >
>>${D}${sysconfdir}/modprobe.d/prohibit_gma500_gfx.conf
>> +}
>
>

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

Re: [meta-intel] [PATCH 1/1] README: Documentation of hardware features

[Kamble, Nitin A]

On 10/3/14, 9:57 AM, "Paul Eggleton"  wrote:

>Hi Nitin,
>
>On Friday 03 October 2014 16:33:28 Kamble, Nitin A wrote:
>> On 10/3/14, 4:15 AM, "Paul Eggleton" 
>>wrote:
>> >On Thursday 02 October 2014 14:14:41 nitin.a.kam...@intel.com wrote:
>> >> From: Nitin A Kamble 
>> >> 
>> >> Starting a new documentation section to describe the layer specific
>> >>
>> >>hardware
>> >>
>> >> features. At this point the intel-ucode machine feature is described
>> >>
>> >>here.
>> >>
>> >> In the future more such features will be described in this section.
>> >
>> >This looks fine to me, thanks for revising it.
>> >
>> >Speaking of the feature itself, I do wonder if going forward whether
>>only
>> >a MACHINE_FEATURES item is the best way to control this though -
>> >particularly if the decision to include it or not is about image size
>>or
>> >policy, users may want to be able to control it at the distro or image
>> >level, and MACHINE_FEATURES is not meant to be changed outside of the
>> >machine configuration. Perhaps we can revisit this in 1.8? (I regret
>>that I
>> >didn't take the opportunity to get involved with this earlier, my
>> >apologies.)
>> 
>> Paul,
>>Thanks for the response. To me it feels best to leave it to machine
>> configuration space. Handling from image or distro configuration space
>> does not seem right. If the machine need/can use updated microcode then
>> that reason is valid for all kinds of distro or image configurations. It
>> is very processor specific decision, and it is best handled in the
>>machine
>> configuration.
>
>You yourself stated:
>
>"The BSPs which are highly sensitive to the target image size, which are
>not 
>experiencing any microcode related issues, may consider not enabling this
>feature to save the target image foot print."
>
>However, it's not really the "BSP" that is sensitive to the target image
>size, 
>for a lot of cases it's going to be dependent on how the device is to be
>used 
>(what storage is going to be used for the image, how large I want my
>image to 
>be, etc.) We may supply a BSP for a device where microcode updates are
>available and can be applied, but that doesn't mean that all usages of
>that 
>device need or want to include the microcode update functionality. Hence
>to my 
>mind it ought to be able to be controlled independently of the BSP.

I think this can be explained better with an example. For example take a
wearable BSP, it would not be building a big image. So the BSP is tied to
a restricted size of the image. Sato or SDK kind of images may not make
any sense for the BSP. In this case the feature can go in the machine
configuration. Ideally it would be nice to have this as a default disabled
feature in the poky-tiny distro, but that is not ideal for the
non-wearable kind of BSPs. I am not trying to reach any conclusion here,
but making sure we have all the information and understanding to make the
right decision. I hope all this clarifications would help you in making
the distro/image feature decision for microcode.

Cheers,
Nitin


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

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

Re: [meta-intel] [PATCH 1/1] README: Documentation of hardware features

[Kamble, Nitin A]

On 10/3/14, 7:26 AM, "Zanussi, Tom"  wrote:

>On Thu, 2014-10-02 at 14:14 -0700, nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> Starting a new documentation section to describe the layer specific
>>hardware
>> features. At this point the intel-ucode machine feature is described
>>here.
>> In the future more such features will be described in this section.
>> 
>> Signed-off-by: Nitin A Kamble 
>> ---
>>  README | 75 
>>++
>>  1 file changed, 75 insertions(+)
>> 
>> diff --git a/README b/README
>> index c829fdb..f633f36 100644
>> --- a/README
>> +++ b/README
>> @@ -83,3 +83,78 @@ The meta-intel maintainers will do their best to
>>review and/or pull in
>>  a patch or patchset within 24 hours of the time it was posted.  For
>>  larger and/or more involved patches and patchsets, the review process
>>  may take longer.
>> +
>> +
>> +Machine Features in the meta-intel layer
>> +
>> +
>> +Many machine features are available in the oecore/poky layer for BSP
>>use.
>> +The meta-intel layer makes some additional machine features available
>>for BSPs
>> +using the meta-intel layer.
>> +
>> +Requirements
>> +
>> +
>> +The additional machine features are only available when the meta-intel
>>layer
>> +is included in the build config, and the meta-intel.inc file is
>>included in
>> +the machine configuration of the interested BSP.
>> +
>> +To make these features available for your machine, you will need to:
>> +
>> +1. have a configuration line as seen below in the bblayers.conf
>> +BBLAYERS += "/meta-intel.git"
>> +2. have the following line in the machine configuration
>> +require conf/machine/include/meta-intel.inc
>> +
>> +Once the above requirements are met, then the machine features
>>provided by
>> +the meta-intel layer will be available for the BSP use.
>> +
>> +Available Machine Features
>> +--
>> +
>> +As of now the meta-intel layer provides the following list of machine
>>features.
>> +In the future, more machine features may be available in this list.
>> +
>> +* intel-ucode
>> +
>> +These machine features can be included by listing them in the
>>MACHINE_FEATURES
>> +variable in the machine configuration file.
>> +
>> +Details of the Machine Features
>> +---
>> +
>> +* intel-ucode: This feature provides microcode updating support for
>>Intel
>> +  processors. With the intel-ucode feature, images get complete
>>support for
>> +  updating the microcode on Intel processors. This feature enables
>>microcode
>> +  updating at early boot time by placing the microcode data files in
>>the
>> +  initrd image. It also puts the user land microcode updating tool
>>iucode_tool
>> +  and the microcode data file in the target images.
>> +
>> +  Q. Why to enable this microcode feature?
>> +  A. Intel releases microcode updates to correct processor behavior as
>> + documented in the respective processor specification updates.
>>While
>> + the regular approach to getting this microcode update is via a
>>BIOS
>> + upgrade, this can be an administrative hassle and not always
>>possible
>> + in the field. The intel-ucode feature enables the microcode update
>> + capability from the Linux OS. It provides an easy path for
>>upgrading
>> + processor microcode without need of changing BIOS. Once the
>>feature
>> + is enabled, it is also possible to update the existing images with
>> + newer microcode update in the future.
>> +
>> +  Q. How to bundle only specific microcodes in the target image?
>> +  A. The Intel microcode data file released by Intel contains microcode
>> + updates for multiple processors. If the BSP image will be running
>>only
>> + on a certain kind of processors, then the number of microcodes
>>bundled in
>> + the target image can be filtered by specifying the
>>UCODE_FILTER_SIGNATURES
>> + variable. A sequence of iucode-tool parameters are listed in the
>> + UCODE_FILTER_SIGNATURES variable to filter the microcodes from the
>> + microcode data file. For more information on these parameters
>>refer to
>> + the iucode-tool manual page, which can be seen over here:
>> +   http://manned.org/iucode-tool
>> +
>
>I took a quick look at the iucode-tool manpage, but didn't see anything
>describing the signatures themselves or where to find them.  It would be
>helpful to the user of this feature to have some idea of where to look
>to find them.  Could you perhaps add a bit about that?

Sure, this would help.

Nitin

>
>Thanks,
>
>Tom
>
>> +  Q. When to not enable this microcode feature?
>> +  A. The microcode datafile and the associated tools take small (few
>>KB)
>> + space on the target image. The BSPs which are highly sensitive to
>>the
>> + target image size, which are not experiencing any microcode
>>related issues,
>> + may consider not enabling this fe

Re: [meta-intel] [PATCH 12/12] fri2-noemgd: add microcode filter parameter

[Kamble, Nitin A]

On 10/3/14, 7:15 AM, "Zanussi, Tom"  wrote:

>On Thu, 2014-10-02 at 11:27 -0700, nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> The fri2-noemgd BSP is targeted to a very specific platform, and it only
>> need microcodes related to a specific processor. So use the microcode
>> filtering mechanism to reduce the unutilized microcode data on the
>>target
>> image.
>> 
>> Signed-off-by: Nitin A Kamble 
>> ---
>>  meta-fri2/conf/machine/fri2-noemgd.conf | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/meta-fri2/conf/machine/fri2-noemgd.conf
>>b/meta-fri2/conf/machine/fri2-noemgd.conf
>> index 345d421..c10ec20 100644
>> --- a/meta-fri2/conf/machine/fri2-noemgd.conf
>> +++ b/meta-fri2/conf/machine/fri2-noemgd.conf
>> @@ -12,6 +12,8 @@ require conf/machine/include/meta-intel.inc
>>  MACHINE_FEATURES += "wifi 3g pcbios efi"
>>  MACHINE_FEATURES += "intel-ucode"
>>  
>> +UCODE_FILTER_SIGNATURES = "-s 0x00020661"
>> +
>
>What does this hex value represent, exactly?  Could you put a comment
>here to explain that, so the next person that comes along has some idea
>what it means.
Yes, a comment should help here.

>
>Also, I'm wondering why the -s is included here - wouldn't it be better
>to hide that from the user and put it in the code that uses it?
More than one signature can be selected here. There are also different
ways of choosing the signatures.

>
>It looks like this variable can be used to specify any iucode tool
>parameter, not just filter signatures.  If so, it needs to have a more
>generic name to reflect that.
It can be changed to UCODE_FILTER_PARAMETERS.

>
>In any case, I think the variable usage needs to be documented in the
>README (I see that it's mentioned, but it doesn't say anything about the
>details of the expected format, etc).  It might make sense to have a
>per-feature subsection for 'related variables' for this purpose, or
>something similar.

Make sense.

Nitin

>
>Tom
>
>
>
>>  MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-iwlwifi-6000g2a-5"
>>  
>>  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
>
>

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

Re: [meta-intel] [PATCH 1/1] README: Documentation of hardware features

[Kamble, Nitin A]

On 10/3/14, 4:15 AM, "Paul Eggleton"  wrote:

>On Thursday 02 October 2014 14:14:41 nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> Starting a new documentation section to describe the layer specific
>>hardware
>> features. At this point the intel-ucode machine feature is described
>>here.
>> In the future more such features will be described in this section.
>
>This looks fine to me, thanks for revising it.
>
>Speaking of the feature itself, I do wonder if going forward whether only
>a 
>MACHINE_FEATURES item is the best way to control this though -
>particularly if 
>the decision to include it or not is about image size or policy, users
>may 
>want to be able to control it at the distro or image level, and
>MACHINE_FEATURES is not meant to be changed outside of the machine
>configuration. Perhaps we can revisit this in 1.8? (I regret that I
>didn't take 
>the opportunity to get involved with this earlier, my apologies.)

Paul,
   Thanks for the response. To me it feels best to leave it to machine
configuration space. Handling from image or distro configuration space
does not seem right. If the machine need/can use updated microcode then
that reason is valid for all kinds of distro or image configurations. It
is very processor specific decision, and it is best handled in the machine
configuration.

Cheers,
Nitin


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

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

Re: [meta-intel] [PATCH V3 2/2] meta-intel/common: Upgrade DPDK to v1.7.0

[Kamble, Nitin A]

On 10/2/14, 6:02 PM, "Ong, Boon Leong"  wrote:

>>Can the QAT & DPDK features be implemented as MACHINE features so
>>that
>> they can be enabled for any BSP. I am doing similar stuff for the intel
>>microcode
>> feature. Once those changes are in, you can try to follow the same
>>logic.
>> 
>QAT is meant for hardware acceleration on specific communication-grade
>chipset like
>Coleto creek, Cave creek, etc. Such technology is not useful for other
>machine.
>
>DPDK is lesser dependent on hardware & mainly used on communication-grade
>platform,
>typically on high-performance grade platform like Romley, etc.
>
>We will need to sync-up on intel microcode feature ...

As these features are applicable to multiple of BSPs, they can be enabled
or disabled in the machine configuration with machine features.

Nitin

>

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

Re: [meta-intel] [PATCH 03/12] README.hardware: Documentation of hardware features

[Kamble, Nitin A]

On 10/2/14, 12:30 PM, "Darren Hart"  wrote:

>On 10/2/14, 12:16, "Tom Zanussi"  wrote:
>
>>On Thu, 2014-10-02 at 11:27 -0700, nitin.a.kam...@intel.com wrote:
>>> From: Nitin A Kamble 
>>> 
>>> Starting a new documentation file to describe the layer specific
>>>hardware
>>> features. At this point the intel-ucode machine feature is described
>>>here.
>>> In the future more such features will be described in this file.
>>> 
>>> Signed-off-by: Nitin A Kamble 
>>> ---
>>>  README.hardware | 88
>>>+
>>
>>Cc:ing Paul, who had a review comment about this from last time:
>>
>>https://lists.yoctoproject.org/pipermail/meta-intel/2014-September/002614
>>.
>>html
>
>Thanks Tom, yes, I thought Paul's point was valid and needs to be
>addressed. It seems to me the layer README is a more appropriate location
>for things like new Machine Feature documentation.

If that is the preferred location, I will move this to the layer README.

Nitin

>
>--
>Darren
>
>>
>>Tom
>>
>>>  1 file changed, 88 insertions(+)
>>>  create mode 100644 README.hardware
>>> 
>>> diff --git a/README.hardware b/README.hardware
>>> new file mode 100644
>>> index 000..e27fb33
>>> --- /dev/null
>>> +++ b/README.hardware
>>> @@ -0,0 +1,88 @@
>>> +meta-intel Layer Hardware README
>>> +
>>> +
>>> +This file gives details about using the meta-intel layer with the
>>>machines
>>> +supported in the layer. A full list of supported reference target
>>>machines
>>> +can be found by looking in the following directories:
>>> +
>>> +   conf/machine/
>>> +   meta-*/conf/machine/
>>> +   meta-isg/meta-*/conf/machine/
>>> +
>>> +The information in this file is also applicable to machines such as as
>>>minnow
>>> +which are defined in separate layers and utilize the meta-intel layer.
>>> +
>>> +
>>> +Machine Features in the meta-intel layer
>>> +
>>> +
>>> +Many machine features are available in the oecore/poky layer for BSP
>>>use.
>>> +The meta-intel layer makes some additional machine features available
>>>for BSPs
>>> +using the meta-intel layer.
>>> +
>>> +Requirements
>>> +
>>> +
>>> +The additional machine features are only available when the meta-intel
>>>layer
>>> +is included in the build config, and the meta-intel.inc file is
>>>included in
>>> +the machine configuration of the interested BSP.
>>> +
>>> +To make these features available for your machine, you will need to:
>>> +
>>> +1. have a configuration line as seen below in the bblayers.conf
>>> +   BBLAYERS += "/meta-intel.git"
>>> +2. have the following line in the machine configuration
>>> +   require conf/machine/include/meta-intel.inc
>>> +
>>> +Once the above requirements are met, then the machine features
>>>provided by
>>> +the meta-intel layer will be available for the BSP use.
>>> +
>>> +Available Machine Features
>>> +--
>>> +
>>> +As of now the meta-intel layer provides the following list of machine
>>>features.
>>> +In the future, more machine features may be available in this list.
>>> +
>>> +* intel-ucode
>>> +
>>> +These machine features can be included by listing them in the
>>>MACHINE_FEATURES
>>> +variable in the machine configuration file.
>>> +
>>> +Details of the Machine Features
>>> +---
>>> +
>>> +* intel-ucode: This feature provides microcode updating support for
>>>Intel
>>> +  processors. With the intel-ucode feature, images get complete
>>>support for
>>> +  updating the microcode on Intel processors. This feature enables
>>>microcode
>>> +  updating at early boot time by placing the microcode data files in
>>>the
>>> +  initrd image. It also puts the user land microcode updating tool
>>>iucode_tool
>>> +  and the microcode data file in the target images.
>>> +
>>> +  Q. Why to enable this microcode feature?
>>> +  A. Intel releases microcode updates to correct processor behavior as
>>> + documented in the respective processor specification updates.
>>>While
>>> + the regular approach to getting this microcode update is via a
>>>BIOS
>>> + upgrade, this can be an administrative hassle and not always
>>>possible
>>> + in the field. The intel-ucode feature enables the microcode
>>>update
>>> + capability from the Linux OS. It provides an easy path for
>>>upgrading
>>> + processor microcode without need of changing BIOS. Once the
>>>feature
>>> + is enabled, it is also possible to update the existing images
>>>with
>>> + newer microcode update in the future.
>>> +
>>> +  Q. How to bundle only specific microcodes in the target image?
>>> +  A. The Intel microcode data file released by Intel contains
>>>microcode
>>> + updates for multiple processors. If the BSP image will be running
>>>only
>>> + on a certain kind of processors, then the number of microcodes
>>>bundled in
>>> + the target image can be fi

Re: [meta-intel] [PATCH V3 2/2] meta-intel/common: Upgrade DPDK to v1.7.0

[Kamble, Nitin A]

Hi BL, Sreeju,

   Can the QAT & DPDK features be implemented as MACHINE features so that
they can be enabled for any BSP. I am doing similar stuff for the intel
microcode feature. Once those changes are in, you can try to follow the
same logic.

Thanks,
Nitin


On 9/30/14, 11:52 PM, "Ong, Boon Leong"  wrote:

>
>
>> -Original Message-
>> From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
>> boun...@yoctoproject.org] On Behalf Of
>> sreeju.armughanx.selva...@intel.com
>> Sent: Tuesday, September 30, 2014 10:43 AM
>> To: meta-intel@yoctoproject.org
>> Subject: [meta-intel] [PATCH V3 2/2] meta-intel/common: Upgrade DPDK to
>> v1.7.0
>> 
>> From: Sreeju Selvaraj 
>> 
>> Added support for DPDK v1.7.0
>> 
>> Added PACKAGECONFIG mechanism to explicitly disable the use of fuse and
>> qat which are dependancies for example apps dpdk_qat and vhost.
>> 
>> Added config variables CONFIG_EXAMPLE_DPDK_QAT and
>> CONFIG_EXAMPLE_DPDK_VHOST to enable or disable the compilation of
>> example apps dpdk_qat and vhost.
>> 
>> Resolved the installation failure found in example app ip_pipeline by
>>cherry
>> picking the patch from dpdk.org.
>> 
>> Resolved the test failure found in example app ring_pmd_autotest by
>>cherry
>> picking the patches from dpdk.org.
>> 
>> Signed-off-by: Sreeju Selvaraj 
>
>Acked-by: Ong Boon Leong 
>
>> ---
>>  ...d-config-variables-to-enable-disable-dpdk.patch |  42 +++
>>...examples-
>> pipeline-build-with-all-examples.patch |  34 ++
>>...e-extra-devices-creation-
>> with-vdev-option.patch |  44 +++
>>.../dpdk/dpdk-1.7.0-ring-simplify-unit-
>> tests.patch | 380 +
>>  common/recipes-extended/dpdk/dpdk_1.7.0.bb |  41 +++
>>  5 files changed, 541 insertions(+)
>>  create mode 100644 common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-
>> examples-Add-config-variables-to-enable-disable-dpdk.patch
>>  create mode 100644 common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-
>> examples-pipeline-build-with-all-examples.patch
>>  create mode 100644 common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-ring-
>> remove-extra-devices-creation-with-vdev-option.patch
>>  create mode 100644 common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-ring-
>> simplify-unit-tests.patch
>>  create mode 100644 common/recipes-extended/dpdk/dpdk_1.7.0.bb
>> 
>> diff --git a/common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-examples-Add-
>> config-variables-to-enable-disable-dpdk.patch b/common/recipes-
>> extended/dpdk/dpdk/dpdk-1.7.0-examples-Add-config-variables-to-enable-
>> disable-dpdk.patch
>> new file mode 100644
>> index 000..d0721ca
>> --- /dev/null
>> +++ b/common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-examples-Add-
>> config-v
>> +++ ariables-to-enable-disable-dpdk.patch
>> @@ -0,0 +1,42 @@
>> +From 63f8ccc5a305b193e219d288ef9e43b9a9fa6aa8 Mon Sep 17 00:00:00 2001
>> +From: Sreeju Selvaraj 
>> +Date: Wed, 17 Sep 2014 19:10:01 +0800
>> +Subject: [PATCH] examples: Add config variables to enable/disable
>> +dpdk_qat and  vhost
>> +
>> +Upstream-Status: Inappropriate [configuration]
>> +
>> +This can be used to export CONFIG_EXAMPLE_DPDK_QAT=n if dpdk_qat is
>> not
>> +in PACKAGECONFIG and also allow to export
>> CONFIG_EXAMPLE_DPDK_VHOST=n
>> +if vhost is not in PACKAGECONFIG.
>> +
>> +Signed-off-by: Sreeju Selvaraj 
>> +---
>> + examples/Makefile | 4 ++--
>> + 1 file changed, 2 insertions(+), 2 deletions(-)
>> +
>> +diff --git a/examples/Makefile b/examples/Makefile index
>> +d0624f6..885c938 100644
>> +--- a/examples/Makefile
>>  b/examples/Makefile
>> +@@ -39,7 +39,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
>> +
>> + DIRS-y += cmdline
>> + ifneq ($(ICP_ROOT),)
>> +-DIRS-y += dpdk_qat
>> ++DIRS-$(CONFIG_EXAMPLE_DPDK_QAT) += dpdk_qat
>> + endif
>> + DIRS-y += exception_path
>> + DIRS-y += helloworld
>> +@@ -61,7 +61,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_METER) += qos_meter
>> + DIRS-$(CONFIG_RTE_LIBRTE_SCHED) += qos_sched  DIRS-y +=
>> +quota_watermark  DIRS-y += timer -DIRS-y += vhost
>> ++DIRS-$(CONFIG_EXAMPLE_DPDK_VHOST) += vhost
>> + DIRS-$(CONFIG_RTE_LIBRTE_XEN_DOM0) += vhost_xen  DIRS-y += vmdq
>> +DIRS-y += vmdq_dcb
>> +--
>> +1.9.1
>> +
>> diff --git a/common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-examples-
>> pipeline-build-with-all-examples.patch b/common/recipes-
>> extended/dpdk/dpdk/dpdk-1.7.0-examples-pipeline-build-with-all-
>> examples.patch
>> new file mode 100644
>> index 000..25f029f
>> --- /dev/null
>> +++ b/common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-examples-pipeline-
>> bui
>> +++ ld-with-all-examples.patch
>> @@ -0,0 +1,34 @@
>> +From 15aef6e666ee2eb0befa153d277d47754f3656e4 Mon Sep 17 00:00:00
>> 2001
>> +From: Thomas Monjalon 
>> +Date: Thu, 17 Jul 2014 10:30:52 +0200
>> +Subject: [PATCH] examples/pipeline: build with all examples
>> +
>> +Upstream-Status: Backport
>> +Imported patch from: http://dpdk.org/browse/dpdk/log/
>> +
>> +When adding this packet framework sample (commit 77a3346), it has been
>> +forgotten to add it into the global makefile for "make examples".
>> +
>> +Si

Re: [meta-intel] [PATCH 2/4] sugarbay.conf: add wifi machine feature

[Kamble, Nitin A]

On 10/1/14, 9:19 AM, "Zanussi, Tom"  wrote:

>On Wed, 2014-10-01 at 11:16 -0500, Kamble, Nitin A wrote:
>> 
>> On 10/1/14, 7:34 AM, "Zanussi, Tom"  wrote:
>> 
>> >On Tue, 2014-09-30 at 19:27 -0700, nitin.a.kam...@intel.com wrote:
>> >> From: Nitin A Kamble 
>> >> 
>> >> The Huron River platform targeted by this BSP has wifi capability.
>> >> The common kernel used by the BSP already has enabled the wifi
>>drivers.
>> >> 
>> >> Enabling the user space wifi tools, which gives functional wifi
>> >>networking
>> >> on the Huron River platform.
>> >> 
>> >> Fixes Bug:
>> >> [YOCTO #6342]
>> >> 
>> >> Signed-off-by: Nitin A Kamble 
>> >> ---
>> >>  meta-sugarbay/conf/machine/sugarbay.conf | 3 +++
>> >>  1 file changed, 3 insertions(+)
>> >> 
>> >> diff --git a/meta-sugarbay/conf/machine/sugarbay.conf
>> >>b/meta-sugarbay/conf/machine/sugarbay.conf
>> >> index de3b002..7d1b0ea 100644
>> >> --- a/meta-sugarbay/conf/machine/sugarbay.conf
>> >> +++ b/meta-sugarbay/conf/machine/sugarbay.conf
>> >> @@ -15,6 +15,9 @@ require
>> >>conf/machine/include/intel-corei7-64-common.inc
>> >>  require conf/machine/include/intel-common-pkgarch.inc
>> >>  
>> >>  MACHINE_HWCODECS ?= "va-intel gst-va-intel"
>> >> +MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"
>> >> +
>> >
>> >This patch also seem to include linux-firmware, which the message says
>> >nothing about.
>> >
>> >Tom
>> 
>> I was counting it in the user space wifi tools as the firmware for the
>> wifi chip is coming from the user space. If you want it mentioned in the
>
>So the firmware for the wifi chip comed from the linux-firmware feature?

Yes. That is why it is included in the BSP. Linux-firmware is a recipe and
not a feature though.

Nitin

>
>Tom
>
>> commit message, it can be done easily.
>> 
>> Nitin
>> 
>> >
>> >
>> >> +MACHINE_FEATURES += "wifi"
>> >>  
>> >>  XSERVER ?= "${XSERVER_X86_BASE} \
>> >> ${XSERVER_X86_EXT} \
>> >
>> >
>> 
>
>

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

Re: [meta-intel] [PATCH 2/4] sugarbay.conf: add wifi machine feature

[Kamble, Nitin A]

On 10/1/14, 7:34 AM, "Zanussi, Tom"  wrote:

>On Tue, 2014-09-30 at 19:27 -0700, nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> The Huron River platform targeted by this BSP has wifi capability.
>> The common kernel used by the BSP already has enabled the wifi drivers.
>> 
>> Enabling the user space wifi tools, which gives functional wifi
>>networking
>> on the Huron River platform.
>> 
>> Fixes Bug:
>> [YOCTO #6342]
>> 
>> Signed-off-by: Nitin A Kamble 
>> ---
>>  meta-sugarbay/conf/machine/sugarbay.conf | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/meta-sugarbay/conf/machine/sugarbay.conf
>>b/meta-sugarbay/conf/machine/sugarbay.conf
>> index de3b002..7d1b0ea 100644
>> --- a/meta-sugarbay/conf/machine/sugarbay.conf
>> +++ b/meta-sugarbay/conf/machine/sugarbay.conf
>> @@ -15,6 +15,9 @@ require
>>conf/machine/include/intel-corei7-64-common.inc
>>  require conf/machine/include/intel-common-pkgarch.inc
>>  
>>  MACHINE_HWCODECS ?= "va-intel gst-va-intel"
>> +MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"
>> +
>
>This patch also seem to include linux-firmware, which the message says
>nothing about.
>
>Tom

I was counting it in the user space wifi tools as the firmware for the
wifi chip is coming from the user space. If you want it mentioned in the
commit message, it can be done easily.

Nitin

>
>
>> +MACHINE_FEATURES += "wifi"
>>  
>>  XSERVER ?= "${XSERVER_X86_BASE} \
>> ${XSERVER_X86_EXT} \
>
>

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

Re: [meta-intel] [PATCH 06/11] crownbay-noemgd: use the v3.17 kernel by default

[Kamble, Nitin A]

On 9/23/14, 5:02 PM, "Zanussi, Tom"  wrote:

>On Tue, 2014-09-23 at 11:32 -0700, nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> Now the linux-yocto_3.17 recipe is available for this BSP. Make it as
>> the default kernel for this BSP.
>> 
>> Signed-off-by: Nitin A Kamble 
>> ---
>>  meta-crownbay/conf/machine/crownbay-noemgd.conf | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/meta-crownbay/conf/machine/crownbay-noemgd.conf
>>b/meta-crownbay/conf/machine/crownbay-noemgd.conf
>> index 4b618a4..634aa5d 100644
>> --- a/meta-crownbay/conf/machine/crownbay-noemgd.conf
>> +++ b/meta-crownbay/conf/machine/crownbay-noemgd.conf
>> @@ -6,7 +6,7 @@
>>  #@DESCRIPTION: Machine configuration for Crown Bay systems, without
>>Intel-proprietary graphics bits
>>  # i.e. E660 + EG20T
>>  
>> -PREFERRED_VERSION_linux-yocto ?= "3.14%"
>> +PREFERRED_VERSION_linux-yocto ?= "3.17%"
>>  
>>  require conf/machine/include/meta-intel.inc
>>  require conf/machine/include/intel-core2-32-common.inc
>
>Seeing this build failure:

Are you able to build the core-image-sato fine? I was able to build and
test it fine.

Looks like the lttng-modules recipe need update for the v3.17 kernel. And
you can open
a bug for that.

Nitin


>
>Build Configuration:
>BB_VERSION= "1.23.2"
>BUILD_SYS = "x86_64-linux"
>NATIVELSBSTRING   = "Ubuntu-12.04"
>TARGET_SYS= "i586-poky-linux"
>MACHINE   = "fri2-noemgd"
>DISTRO= "poky"
>DISTRO_VERSION= "1.6+snapshot-20140923"
>TUNE_FEATURES = "m32 core2"
>TARGET_FPU= ""
>meta  
>meta-yocto
>meta-yocto-bsp= "master8:afdbe3112b940987f3f3cddcb32c91a5e17a297d"
>meta-intel
>meta-fri2 = "master27:6c89b8ac95d812c0963a874bc0e6a8a1e69fbece"
>
>NOTE: Preparing runqueue
>NOTE: Executing SetScene Tasks
>NOTE: Executing RunQueue Tasks
>WARNING: Failed to fetch URL
>http://01.org/powertop/sites/default/files/downloads/powertop-2.6.1.tar.gz
>, attempting MIRRORS if available
>NOTE: validating kernel config, see log.do_kernel_configcheck for details
>ERROR: Function failed: do_compile (log file is located at
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/temp/log.do_compile.2567)
>ERROR: Logfile of failure stored in:
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/temp/log.do_compile.2567
>Log data follows:
>| DEBUG: Executing shell function do_compile
>| NOTE: make -j 8 -e MAKEFLAGS=
>KERNEL_PATH=/usr/local/src/yocto/isg-test/build/tmp/sysroots/fri2-noemgd/u
>sr/src/kernel 
>KERNEL_SRC=/usr/local/src/yocto/isg-test/build/tmp/sysroots/fri2-noemgd/us
>r/src/kernel KERNEL_VERSION=3.17.0-rc4-yocto-standard
>CC=i586-poky-linux-gcc  LD=i586-poky-linux-ld.bfd  AR=i586-poky-linux-ar
>| make -C 
>/usr/local/src/yocto/isg-test/build/tmp/sysroots/fri2-noemgd/usr/src/kerne
>l 
>M=/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttn
>g-modules/2.5.0-r0/git modules
>| make[1]: Entering directory
>`/usr/local/src/yocto/isg-test/build/tmp/sysroots/fri2-noemgd/usr/src/kern
>el'
>|   CC [M]  
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/git/lttng-ring-buffer-client-discard.o
>|   CC [M]  
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/git/lttng-ring-buffer-client-overwrite.o
>|   CC [M]  
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/git/lttng-ring-buffer-metadata-client.o
>|   CC [M]  
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/git/lttng-ring-buffer-client-mmap-discard.o
>|   CC [M]  
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/git/lttng-ring-buffer-client-mmap-overwrite.o
>|   CC [M]  
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/git/lttng-ring-buffer-metadata-mmap-client.o
>|   CC [M]  
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/git/lttng-statedump-impl.o
>|   CC [M]  
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/git/wrapper/irqdesc.o
>|   CC [M]  
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/git/wrapper/fdtable.o
>|   CC [M]  
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/git/lttng-events.o
>|   CC [M]  
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/git/lttng-abi.o
>|   CC [M]  
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/git/lttng-probes.o
>|   CC [M]  
>/usr/local/src/yocto/isg-test/build/tmp/work/fri2_noemgd-poky-linux/lttng-
>modules/2.5.0-r0/git/lttng-context.o
>|   CC [M]  
>/usr/local/src/yocto/isg-test/bui

Re: [meta-intel] [PATCH 00/11] v3.17 kernel commits for meta-intel

[Kamble, Nitin A]

On 9/23/14, 12:32 PM, "Zanussi, Tom"  wrote:

>On Tue, 2014-09-23 at 11:32 -0700, nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> The linux-yocto v3.17 kernel recipe is available in oecore layer. These
>> commits extend it for use of the meta-intel BSPs.
>> 
>> Also some miscellaneous fixes toe the machine configurations are
>>included.
>> 
>> All these commits are validated on the corresponding BSP hardware.
>> 
>> Thanks,
>> Nitin
>> 
>> The following changes since commit
>>a369fa8f2d76528cb296ef9314e613e26585d54d:
>> 
>>   layer.conf: Bumping LAYERVERSION (2014-09-18 18:35:54 -0500)
>> 
>> are available in the git repository at:
>> 
>>   git://git.yoctoproject.org/meta-intel-contrib
>>refs/nitin/v3.17-kernel-commits
>>   
>>http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin/v3.1
>>7-kernel-commits
>> 
>
>Is that the right branch?  I'm not seeing it in meta-intel-contrib after
>update:

Something is messed up on the contrib git repo. At least the above link is
working.

Nitin

>
>$ git branch -a
>
>  remotes/meta-intel-contrib/nitin/abt
>  remotes/meta-intel-contrib/nitin/bsp-ng2
>  remotes/meta-intel-contrib/nitin/danny
>  remotes/meta-intel-contrib/nitin/dora
>  remotes/meta-intel-contrib/nitin/dylan
>  remotes/meta-intel-contrib/nitin/dylan+work
>  remotes/meta-intel-contrib/nitin/elcdemo/meta-intel
>  remotes/meta-intel-contrib/nitin/emenlow+emgd
>  remotes/meta-intel-contrib/nitin/emenlow-emgd
>  remotes/meta-intel-contrib/nitin/fri2-noemgd-Xfbdev
>  remotes/meta-intel-contrib/nitin/hwcodec
>  remotes/meta-intel-contrib/nitin/imageconfigurator
>  remotes/meta-intel-contrib/nitin/libva-work
>  remotes/meta-intel-contrib/nitin/master+work
>  remotes/meta-intel-contrib/nitin/mesa-gl
>  remotes/meta-intel-contrib/nitin/mesagl
>  remotes/meta-intel-contrib/nitin/minnow
>  remotes/meta-intel-contrib/nitin/misc
>  remotes/meta-intel-contrib/nitin/misc2
>  remotes/meta-intel-contrib/nitin/misc3
>  remotes/meta-intel-contrib/nitin/ntb
>  remotes/meta-intel-contrib/nitin/ntb2
>  remotes/meta-intel-contrib/nitin/nuc
>  remotes/meta-intel-contrib/nitin/tmp1
>  remotes/meta-intel-contrib/nitin/ucode
>  remotes/meta-intel-contrib/nitin/wip
>  remotes/meta-intel-contrib/nitin/work
>  remotes/meta-intel-contrib/nitin/zaurusd
>  remotes/meta-intel-contrib/nitin/zaurusd-enhancements
>
>
>> Nitin A Kamble (11):
>>   fri2-noemgd.conf: soften the preferred kernel version assignment
>>   emenlow-noemgd: use the common kernel
>>   linux-yocto_3.17.bbappend for the meta-intel BSPs
>>   intel-core2-32: use the v3.17 kernel by default
>>   intel-corei7-64: use the v3.17 kernel by default
>>   crownbay-noemgd: use the v3.17 kernel by default
>>   emenlow-noemgd: use the v3.17 kernel by default
>>   fri2-noemgd: use the v3.17 kernel by default
>>   jasperforest: use the v4.17 kernel by default
>>   nuc: use the v4.17 kernel by default
>>   sugarbay: use the v4.17 kernel by default
>> 
>>  .../recipes-kernel/linux/linux-yocto_3.17.bbappend | 28
>>++
>>  conf/machine/intel-core2-32.conf   |  2 +-
>>  conf/machine/intel-corei7-64.conf  |  2 +-
>>  meta-crownbay/conf/machine/crownbay-noemgd.conf|  2 +-
>>  meta-emenlow/conf/machine/emenlow-noemgd.conf  |  3 ++-
>>  meta-fri2/conf/machine/fri2-noemgd.conf|  2 +-
>>  meta-jasperforest/conf/machine/jasperforest.conf   |  2 +-
>>  meta-nuc/conf/machine/nuc.conf |  2 +-
>>  meta-sugarbay/conf/machine/sugarbay.conf   |  2 +-
>>  9 files changed, 37 insertions(+), 8 deletions(-)
>>  create mode 100644
>>common/recipes-kernel/linux/linux-yocto_3.17.bbappend
>> 
>
>

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

Re: [meta-intel] [PATCH 21/31] machinesetuptool: a new recipe for setup of a machine

[Kamble, Nitin A]

>
>Yeah, it might be time for that. For the time being, a blurb in the common
>README should be sufficient with a Documentation/ project being a separate
>effort.
>


Compared to the README file, the README.hardware file seems like a better
place for this documentation. Any concerns with it?

Thanks,
Nitin

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

Re: [meta-intel] [PATCH 21/31] machinesetuptool: a new recipe for setup of a machine

[Kamble, Nitin A]

On 9/22/14, 11:25 AM, "Zanussi, Tom"  wrote:

>On Mon, 2014-09-22 at 12:23 -0500, Kamble, Nitin A wrote:
>> 
>> On 9/22/14, 6:48 AM, "Zanussi, Tom"  wrote:
>> 
>> >On Fri, 2014-09-19 at 17:35 -0700, Darren Hart wrote:
>> >> On Thu, Sep 18, 2014 at 05:35:41PM -0700, nitin.a.kam...@intel.com
>> >>wrote:
>> >> > From: Nitin A Kamble 
>> >> > 
>> >> > This recipe adds ability to setup a BSP image for a specific
>>machine
>> >>or
>> >> > platform at the boot time. The base recipe does not provide any
>> >>machine
>> >> > configuration files, and the required machine configuration files
>>are
>> >> > to be provided in the BSP layers.
>> >> > 
>> >> > This recipe is currently split in 2 files for ease of future
>> >>migration of
>> >> > the base recipe to the oecore layer.
>> >> > 
>> >> > Signed-off-by: Nitin A Kamble 
>> >> > ---
>> >> >  .../machinesetuptool/machinesetuptool_git.bb   | 49
>> >>++
>> >> >  1 file changed, 49 insertions(+)
>> >> >  create mode 100644
>> >>common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> >> > 
>> >> > diff --git 
>> >>a/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> >>b/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> >> > new file mode 100644
>> >> > index 000..0dfe242
>> >> > --- /dev/null
>> >> > +++ b/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> >> > @@ -0,0 +1,49 @@
>> >> > +SUMMARY = "Daemon to setup an image for a specific machine at boot
>> >>time."
>> >> > +SECTION = "base"
>> >> > +LICENSE = "GPLv3"
>> >> > +LIC_FILES_CHKSUM =
>> >>"file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
>> >> > +RDEPENDS_${PN} = "sysvinit sed"
>> >> > +
>> >> > +PV = "1.0+git${SRCPV}"
>> >> > +
>> >> > +SRCREV = "4cb28ca5de3385f6e16a1e3f69b1a8a79b75ace4"
>> >> > +
>> >> > +SRC_URI = "git://git.yoctoproject.org/machinesetuptool.git"
>> >> > +
>> >> > +S = "${WORKDIR}/git"
>> >> > +
>> >> > +PACKAGE_ARCH = "${MACHINE_ARCH}"
>> >> > +
>> >> > +inherit autotools pkgconfig update-rc.d
>> >> > +
>> >> > +INITSCRIPT_NAME = "machinesetuptool"
>> >> > +INITSCRIPT_PARAMS = "start 00 S . stop 20 0 1 6 ."
>> >> 
>> >> Are these deliberate, or possibly copied from something else?
>> >> 
>> >> > +
>> >> > +RRECOMMENDS_${PN} += "kernel-module-uinput"
>> >> > +
>> >> 
>> >> Why does the machinesetuptool recommend a specific kernel module?
>> >> 
>> >> > +python __anonymous () {
>> >> > +src_uri = d.getVar('SRC_URI', True)
>> >> > +machine_config_files = (d.getVar('MACHINE_CONFIG_FILES', True)
>> >>or "")
>> >> > +for file in machine_config_files.split():
>> >> > + src_uri += " file://" + file
>> >> > +d.setVar('SRC_URI', src_uri)
>> >> > +}
>> >> 
>> >> Hrm, does this dynamic SRC_URI creation play nice with all the
>>bitbake
>> >>hashing
>> >> of recipes and such?
>> >> 
>> >> > +
>> >> > +do_install_append() {
>> >> > +   {
>> >> > +   echo SUPPORTED_MACHINES=\"${SUPPORTED_MACHINES}\"
>> >> > +   echo DEFAULT_MACHINE_SELECTION=${DEFAULT_MACHINE_SELECTION}
>> >> 
>> >> One quoted, one not.. should probably be consistent...
>> >> 
>> >> > +   } > ${D}/${sysconfdir}/${BPN}/defaults
>> >> 
>> >> I'd suggest a HERE document here.
>> >> 
>> >> http://tldp.org/LDP/abs/html/here-docs.html
>> >> 
>> >> (cat << EOF
>> >> SUPPORTED_MACHINE="${SUPPORTED_MACHINES"
>> >> DEFAULT_MACHINE_SELECTION="${DEFAULT_MACHINE_SELECTION}"
>> >>

Re: [meta-intel] [PATCH 21/31] machinesetuptool: a new recipe for setup of a machine

[Kamble, Nitin A]

On 9/22/14, 6:48 AM, "Zanussi, Tom"  wrote:

>On Fri, 2014-09-19 at 17:35 -0700, Darren Hart wrote:
>> On Thu, Sep 18, 2014 at 05:35:41PM -0700, nitin.a.kam...@intel.com
>>wrote:
>> > From: Nitin A Kamble 
>> > 
>> > This recipe adds ability to setup a BSP image for a specific machine
>>or
>> > platform at the boot time. The base recipe does not provide any
>>machine
>> > configuration files, and the required machine configuration files are
>> > to be provided in the BSP layers.
>> > 
>> > This recipe is currently split in 2 files for ease of future
>>migration of
>> > the base recipe to the oecore layer.
>> > 
>> > Signed-off-by: Nitin A Kamble 
>> > ---
>> >  .../machinesetuptool/machinesetuptool_git.bb   | 49
>>++
>> >  1 file changed, 49 insertions(+)
>> >  create mode 100644
>>common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> > 
>> > diff --git 
>>a/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>>b/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> > new file mode 100644
>> > index 000..0dfe242
>> > --- /dev/null
>> > +++ b/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> > @@ -0,0 +1,49 @@
>> > +SUMMARY = "Daemon to setup an image for a specific machine at boot
>>time."
>> > +SECTION = "base"
>> > +LICENSE = "GPLv3"
>> > +LIC_FILES_CHKSUM =
>>"file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
>> > +RDEPENDS_${PN} = "sysvinit sed"
>> > +
>> > +PV = "1.0+git${SRCPV}"
>> > +
>> > +SRCREV = "4cb28ca5de3385f6e16a1e3f69b1a8a79b75ace4"
>> > +
>> > +SRC_URI = "git://git.yoctoproject.org/machinesetuptool.git"
>> > +
>> > +S = "${WORKDIR}/git"
>> > +
>> > +PACKAGE_ARCH = "${MACHINE_ARCH}"
>> > +
>> > +inherit autotools pkgconfig update-rc.d
>> > +
>> > +INITSCRIPT_NAME = "machinesetuptool"
>> > +INITSCRIPT_PARAMS = "start 00 S . stop 20 0 1 6 ."
>> 
>> Are these deliberate, or possibly copied from something else?
>> 
>> > +
>> > +RRECOMMENDS_${PN} += "kernel-module-uinput"
>> > +
>> 
>> Why does the machinesetuptool recommend a specific kernel module?
>> 
>> > +python __anonymous () {
>> > +src_uri = d.getVar('SRC_URI', True)
>> > +machine_config_files = (d.getVar('MACHINE_CONFIG_FILES', True)
>>or "")
>> > +for file in machine_config_files.split():
>> > + src_uri += " file://" + file
>> > +d.setVar('SRC_URI', src_uri)
>> > +}
>> 
>> Hrm, does this dynamic SRC_URI creation play nice with all the bitbake
>>hashing
>> of recipes and such?
>> 
>> > +
>> > +do_install_append() {
>> > +  {
>> > +  echo SUPPORTED_MACHINES=\"${SUPPORTED_MACHINES}\"
>> > +  echo DEFAULT_MACHINE_SELECTION=${DEFAULT_MACHINE_SELECTION}
>> 
>> One quoted, one not.. should probably be consistent...
>> 
>> > +  } > ${D}/${sysconfdir}/${BPN}/defaults
>> 
>> I'd suggest a HERE document here.
>> 
>> http://tldp.org/LDP/abs/html/here-docs.html
>> 
>> (cat << EOF
>> SUPPORTED_MACHINE="${SUPPORTED_MACHINES"
>> DEFAULT_MACHINE_SELECTION="${DEFAULT_MACHINE_SELECTION}"
>> EOF
>> ) > ${D}/${sysconfdir}/${BPN}/defaults
>> 
>> Tested with bash and dash
>> 
>> > +
>> > +  for file in ${MACHINE_CONFIG_FILES}
>> > +  do
>> > +  install -m 0644 ${S}/../${file} 
>> > ${D}/${sysconfdir}/${BPN}/config/
>> > +  done
>> > +}
>> > +
>> > +# following variables are initialized to empty values now.
>> > +# These need to be populated with the desired machine configurations
>> > +# for each BSP in it's own layer.
>> > +MACHINE_CONFIG_FILES = ""
>> > +SUPPORTED_MACHINES = ""
>> > +DEFAULT_MACHINE_SELECTION = "none"
>> 
>> I'd move these above where they are used, and I'd assign them with ?=
>>instead of
>> =.
>> 
>> Before including this feature, I would also like to review the
>>machinesetuptool
>> itself.
>> 
>
>And for that matter, why is it in a separate repo at all?  It doesn't
>have any use outside of oe-core, correct?  Why not move it
>into /scripts?

It needs the build support files as well. Like the configure, makefile
etc. Will all these additional files can be populated in the script
directory ?

Nitin

>
>Tom
>
>> --
>> Darren Hart
>> Intel Open Source Technology Center
>
>

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

Re: [meta-intel] [PATCH 23/31] machinesetuptool: add jasperforest machine config to the intel-corei7-64 BSP

[Kamble, Nitin A]

On 9/19/14, 5:52 PM, "Darren Hart"  wrote:

>On Thu, Sep 18, 2014 at 05:35:43PM -0700, nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> Add machine configuration for the Jasperforest platform in the
>>intel-corei7-64 BSP image.
>> 
>> Signed-off-by: Nitin A Kamble 
>> ---
>>  .../intel-corei7-64/jasperforest-alsa.conf |  1 +
>>  .../jasperforest-formfactor.machconfig |  3 +++
>>  .../jasperforest-network.interfaces| 31
>>++
>
>Same question here, looks to be basically the same as the one for the nuc.
>Should this just be the default for intel-common* and we can override per
>machine if we want something more specific.

These configs need to be trimmed and made more machine specific.

It¹s better to keep a separate config files for each of the machines. It
helps at the time of reconfiguration of the image for a different machine.

Nitin

>
>-- 
>Darren Hart
>Intel Open Source Technology Center

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

Re: [meta-intel] [PATCH 22/31] machinesetuptool: add nuc machine config to the intel-corei7-64 BSP

[Kamble, Nitin A]

On 9/19/14, 5:50 PM, "Darren Hart"  wrote:

>On Thu, Sep 18, 2014 at 05:35:42PM -0700, nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> Add machine configuration for the NUC platform in the intel-corei7-64
>>BSP image.
>> 
>> Signed-off-by: Nitin A Kamble 
>> ---
>>  .../machinesetuptool/intel-corei7-64/nuc-alsa.conf |  24 ++
>>  .../intel-corei7-64/nuc-alsa.state | 309
>>+
>>  .../nuc-bootscript-hdmi_port_audio.sh  |  19 ++
>
>So on alsa and HDMI, I've discussed this with some alsa devs and I got the
>impression this sort of machine specific configuration should not be
>necessary.
>I'd suggest connecting with Mengdong Lin and discussing options for a more
>generic means to enable alsa and HDMI.

I am pinging Megdong privately on this.

>
>>  .../intel-corei7-64/nuc-formfactor.machconfig  |   3 +
>>  .../intel-corei7-64/nuc-network.interfaces |  31 +++
>>  .../machinesetuptool/intel-corei7-64/nuc.vars  |  14 +
>>  .../machinesetuptool/machinesetuptool_git.bbappend |  18 ++
>>  7 files changed, 418 insertions(+)
>>  create mode 100644
>>common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc-
>>alsa.conf
>>  create mode 100644
>>common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc-
>>alsa.state
>>  create mode 100755
>>common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc-
>>bootscript-hdmi_port_audio.sh
>>  create mode 100644
>>common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc-
>>formfactor.machconfig
>>  create mode 100644
>>common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc-
>>network.interfaces
>>  create mode 100644
>>common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nuc.
>>vars
>>  create mode 100644
>>common/recipes-bsp/machinesetuptool/machinesetuptool_git.bbappend
>> 
>
>...
>
>> diff --git 
>>a/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nu
>>c-network.interfaces
>>b/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nu
>>c-network.interfaces
>> new file mode 100644
>> index 000..0acf4cf
>> --- /dev/null
>> +++ 
>>b/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nu
>>c-network.interfaces
>> @@ -0,0 +1,31 @@
>> +# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
>> + 
>> +# The loopback interface
>> +auto lo
>> +iface lo inet loopback
>> +
>> +# Wireless interfaces
>> +iface wlan0 inet dhcp
>> +wireless_mode managed
>> +wireless_essid any
>> +wpa-driver wext
>> +wpa-conf /etc/wpa_supplicant.conf
>> +
>> +iface atml0 inet dhcp
>> +
>> +# Wired or wireless interfaces
>> +auto eth0
>> +iface eth0 inet dhcp
>> +iface eth1 inet dhcp
>
>Does the nuc really have all these interfaces? Seems like a lot of
>generic bits
>for a machine-specific config...

I just picked this from the NUC BSP. Clearly it needs trimming.


>
>> +
>> +# Ethernet/RNDIS gadget (g_ether)
>> +# ... or on host side, usbnet and random hwaddr
>> +iface usb0 inet static
>> +address 192.168.7.2
>> +netmask 255.255.255.0
>> +network 192.168.7.0
>> +gateway 192.168.7.1
>> +
>> +# Bluetooth networking
>> +iface bnep0 inet dhcp
>> +
>> diff --git 
>>a/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nu
>>c.vars 
>>b/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nu
>>c.vars
>> new file mode 100644
>> index 000..c6f373f
>> --- /dev/null
>> +++ 
>>b/common/recipes-bsp/machinesetuptool/machinesetuptool/intel-corei7-64/nu
>>c.vars
>> @@ -0,0 +1,14 @@
>> +FORMFACTOR_FILE="nuc-formfactor.machconfig"
>> +ALSA_CONFIG_FILE="nuc-alsa.conf"
>> +ALSA_STATE_FILE="nuc-alsa.state"
>> +XORG_CONFIG_FILE=""
>> +NETWORK_INTERFACES_FILE="nuc-network.interfaces"
>> +AUTOLOAD_KERNEL_MODULES="uio iwlwifi"
>
>Don't we already do this for the intel-common kernel?


Yes, but with this change it will be removed from the generic BSP kernel,
and enabled as per the platform here.

>
>-- 
>Darren Hart
>Intel Open Source Technology Center

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

Re: [meta-intel] [PATCH 21/31] machinesetuptool: a new recipe for setup of a machine

[Kamble, Nitin A]

On 9/19/14, 5:35 PM, "Darren Hart"  wrote:

>On Thu, Sep 18, 2014 at 05:35:41PM -0700, nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> This recipe adds ability to setup a BSP image for a specific machine or
>> platform at the boot time. The base recipe does not provide any machine
>> configuration files, and the required machine configuration files are
>> to be provided in the BSP layers.
>> 
>> This recipe is currently split in 2 files for ease of future migration
>>of
>> the base recipe to the oecore layer.
>> 
>> Signed-off-by: Nitin A Kamble 
>> ---
>>  .../machinesetuptool/machinesetuptool_git.bb   | 49
>>++
>>  1 file changed, 49 insertions(+)
>>  create mode 100644
>>common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> 
>> diff --git 
>>a/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>>b/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> new file mode 100644
>> index 000..0dfe242
>> --- /dev/null
>> +++ b/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> @@ -0,0 +1,49 @@
>> +SUMMARY = "Daemon to setup an image for a specific machine at boot
>>time."
>> +SECTION = "base"
>> +LICENSE = "GPLv3"
>> +LIC_FILES_CHKSUM =
>>"file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
>> +RDEPENDS_${PN} = "sysvinit sed"
>> +
>> +PV = "1.0+git${SRCPV}"
>> +
>> +SRCREV = "4cb28ca5de3385f6e16a1e3f69b1a8a79b75ace4"
>> +
>> +SRC_URI = "git://git.yoctoproject.org/machinesetuptool.git"
>> +
>> +S = "${WORKDIR}/git"
>> +
>> +PACKAGE_ARCH = "${MACHINE_ARCH}"
>> +
>> +inherit autotools pkgconfig update-rc.d
>> +
>> +INITSCRIPT_NAME = "machinesetuptool"
>> +INITSCRIPT_PARAMS = "start 00 S . stop 20 0 1 6 ."
>
>Are these deliberate, or possibly copied from something else?

Both. This are coming from zaurusd recipe, and I customized it further.

>
>> +
>> +RRECOMMENDS_${PN} += "kernel-module-uinput"
>> +
>
>Why does the machinesetuptool recommend a specific kernel module?

This also came from the zaurusd, and I believe it¹s purpose to ensure the
ability to get user input at the boot time.

>
>> +python __anonymous () {
>> +src_uri = d.getVar('SRC_URI', True)
>> +machine_config_files = (d.getVar('MACHINE_CONFIG_FILES', True) or
>>"")
>> +for file in machine_config_files.split():
>> + src_uri += " file://" + file
>> +d.setVar('SRC_URI', src_uri)
>> +}
>
>Hrm, does this dynamic SRC_URI creation play nice with all the bitbake
>hashing
>of recipes and such?

It is working fine in my testing. Also I don¹t see why it would cause any
problems with bitbake hashes to determine the recipe has changed or not.

>
>> +
>> +do_install_append() {
>> +{
>> +echo SUPPORTED_MACHINES=\"${SUPPORTED_MACHINES}\"
>> +echo DEFAULT_MACHINE_SELECTION=${DEFAULT_MACHINE_SELECTION}
>
>One quoted, one not.. should probably be consistent...

The quoted can have space in the variable definition. Other does not have
space. But it will not hurt putting quotes there.
>
>> +} > ${D}/${sysconfdir}/${BPN}/defaults
>
>I'd suggest a HERE document here.
>
>http://tldp.org/LDP/abs/html/here-docs.html
>
>(cat << EOF
>SUPPORTED_MACHINE="${SUPPORTED_MACHINES"
>DEFAULT_MACHINE_SELECTION="${DEFAULT_MACHINE_SELECTION}"
>EOF
>) > ${D}/${sysconfdir}/${BPN}/defaults
>
>Tested with bash and dash
Good. Was there any functional issue with the previous approach? Or the
change is mainly for the style reasons.

>
>> +
>> +for file in ${MACHINE_CONFIG_FILES}
>> +do
>> +install -m 0644 ${S}/../${file} 
>> ${D}/${sysconfdir}/${BPN}/config/
>> +done
>> +}
>> +
>> +# following variables are initialized to empty values now.
>> +# These need to be populated with the desired machine configurations
>> +# for each BSP in it's own layer.
>> +MACHINE_CONFIG_FILES = ""
>> +SUPPORTED_MACHINES = ""
>> +DEFAULT_MACHINE_SELECTION = "none"
>
>I'd move these above where they are used, and I'd assign them with ?=
>instead of
>=.

Makes sense.

>
>Before including this feature, I would also like to review the
>machinesetuptool
>itself.

http://git.yoctoproject.org/cgit/cgit.cgi/machinesetuptool/commit/?id=4cb28
ca5de3385f6e16a1e3f69b1a8a79b75ace4


Another question is shall the emenlow machine be named here as
"emenlow-noemgd" or it can be "emenlow², because there is no legacy to
consider in this space.


Thanks for the review Darren,
Nitin

>--
>Darren Hart
>Intel Open Source Technology Center

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

Re: [meta-intel] [PATCH 21/31] machinesetuptool: a new recipe for setup of a machine

[Kamble, Nitin A]

On 9/19/14, 9:41 AM, "Zanussi, Tom"  wrote:

>On Fri, 2014-09-19 at 11:31 -0500, Kamble, Nitin A wrote:
>> 
>> On 9/19/14, 6:52 AM, "Zanussi, Tom"  wrote:
>> 
>> >On Thu, 2014-09-18 at 17:35 -0700, nitin.a.kam...@intel.com wrote:
>> >> From: Nitin A Kamble 
>> >> 
>> >> This recipe adds ability to setup a BSP image for a specific machine
>>or
>> >> platform at the boot time. The base recipe does not provide any
>>machine
>> >> configuration files, and the required machine configuration files are
>> >> to be provided in the BSP layers.
>> >> 
>> >> This recipe is currently split in 2 files for ease of future
>>migration
>> >>of
>> >> the base recipe to the oecore layer.
>> >> 
>> >
>> >This seems like fairly significant new functionality to go in
>>completely
>> >undocumented.  I'd expect to see at least something that explains the
>> >basics of what it is, how it works, why it's needed, what functionality
>> >it's meant to replace, and especially how users are supposed to use it
>> >and what the interface is.
>> 
>> Yes, Documentation is pending, but before I go there, I would like to
>>get
>> the code in so that the interfaces are officially finalized.
>
>Well, documentation will be needed in any case, and it really helps to
>give reviewers an idea of what they're looking at, rather than having
>them waste time trying to puzzle out the interfaces and intentions.
>
>I'm guessing that any documentation you'd create now wouldn't have to be
>completely rewritten, so it shouldn't be too onerous a task to update
>those along with any code changes.

Ok, And where should this documentation go? Some of it I have included in
the sources of the machinesetuptool itself. Some sample configuration is
also included in the code repository. I can create a new file names
README.machinesetuptool in the top directory of meta-intel layer. Will
that work?

Nitin


>
>Tom
>
>> >
>> >Also, if we pull this in, and then as implied by your last sentence,
>> >it's migrated to oe-core and runs into resistance or needs to be
>>changed
>> >significantly, are we stuck supporting a conflicting interface in
>> >meta-intel forever?  If so, and it's ultimately intended to live in
>> >oe-core, I'd suggest it just wait to undergo a proper review in that
>> >context in the 1.8 timeframe.
>> 
>> Good points here Tom. Darren what do you recommend?
>> 
>> Thanks,
>> Nitin
>> 
>> >
>> >Tom
>> >
>> >> Signed-off-by: Nitin A Kamble 
>> >> ---
>> >>  .../machinesetuptool/machinesetuptool_git.bb   | 49
>> >>++
>> >>  1 file changed, 49 insertions(+)
>> >>  create mode 100644
>> >>common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> >> 
>> >> diff --git 
>> >>a/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> >>b/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> >> new file mode 100644
>> >> index 000..0dfe242
>> >> --- /dev/null
>> >> +++ b/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> >> @@ -0,0 +1,49 @@
>> >> +SUMMARY = "Daemon to setup an image for a specific machine at boot
>> >>time."
>> >> +SECTION = "base"
>> >> +LICENSE = "GPLv3"
>> >> +LIC_FILES_CHKSUM =
>> >>"file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
>> >> +RDEPENDS_${PN} = "sysvinit sed"
>> >> +
>> >> +PV = "1.0+git${SRCPV}"
>> >> +
>> >> +SRCREV = "4cb28ca5de3385f6e16a1e3f69b1a8a79b75ace4"
>> >> +
>> >> +SRC_URI = "git://git.yoctoproject.org/machinesetuptool.git"
>> >> +
>> >> +S = "${WORKDIR}/git"
>> >> +
>> >> +PACKAGE_ARCH = "${MACHINE_ARCH}"
>> >> +
>> >> +inherit autotools pkgconfig update-rc.d
>> >> +
>> >> +INITSCRIPT_NAME = "machinesetuptool"
>> >> +INITSCRIPT_PARAMS = "start 00 S . stop 20 0 1 6 ."
>> >> +
>> >> +RRECOMMENDS_${PN} += "kernel-module-uinput"
>> >> +
>> >> +python __anonymous () {
>> >> +src_uri = d.getVar('SRC_URI', True)
>> >> +machine_config_files = (d.getVar('MACHINE_CONFIG_FILES', True)
>>or
>> >>"")
>> >> +for file in machine_config_files.split():
>> >> + src_uri += " file://" + file
>> >> +d.setVar('SRC_URI', src_uri)
>> >> +}
>> >> +
>> >> +do_install_append() {
>> >> + {
>> >> + echo SUPPORTED_MACHINES=\"${SUPPORTED_MACHINES}\"
>> >> + echo DEFAULT_MACHINE_SELECTION=${DEFAULT_MACHINE_SELECTION}
>> >> + } > ${D}/${sysconfdir}/${BPN}/defaults
>> >> +
>> >> + for file in ${MACHINE_CONFIG_FILES}
>> >> + do
>> >> + install -m 0644 ${S}/../${file} 
>> >> ${D}/${sysconfdir}/${BPN}/config/
>> >> + done
>> >> +}
>> >> +
>> >> +# following variables are initialized to empty values now.
>> >> +# These need to be populated with the desired machine configurations
>> >> +# for each BSP in it's own layer.
>> >> +MACHINE_CONFIG_FILES = ""
>> >> +SUPPORTED_MACHINES = ""
>> >> +DEFAULT_MACHINE_SELECTION = "none"
>> >
>> >
>> 
>
>

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

Re: [meta-intel] [PATCH 21/31] machinesetuptool: a new recipe for setup of a machine

[Kamble, Nitin A]

On 9/19/14, 6:52 AM, "Zanussi, Tom"  wrote:

>On Thu, 2014-09-18 at 17:35 -0700, nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> This recipe adds ability to setup a BSP image for a specific machine or
>> platform at the boot time. The base recipe does not provide any machine
>> configuration files, and the required machine configuration files are
>> to be provided in the BSP layers.
>> 
>> This recipe is currently split in 2 files for ease of future migration
>>of
>> the base recipe to the oecore layer.
>> 
>
>This seems like fairly significant new functionality to go in completely
>undocumented.  I'd expect to see at least something that explains the
>basics of what it is, how it works, why it's needed, what functionality
>it's meant to replace, and especially how users are supposed to use it
>and what the interface is.

Yes, Documentation is pending, but before I go there, I would like to get
the code in so that the interfaces are officially finalized.

>
>Also, if we pull this in, and then as implied by your last sentence,
>it's migrated to oe-core and runs into resistance or needs to be changed
>significantly, are we stuck supporting a conflicting interface in
>meta-intel forever?  If so, and it's ultimately intended to live in
>oe-core, I'd suggest it just wait to undergo a proper review in that
>context in the 1.8 timeframe.

Good points here Tom. Darren what do you recommend?

Thanks,
Nitin

>
>Tom
>
>> Signed-off-by: Nitin A Kamble 
>> ---
>>  .../machinesetuptool/machinesetuptool_git.bb   | 49
>>++
>>  1 file changed, 49 insertions(+)
>>  create mode 100644
>>common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> 
>> diff --git 
>>a/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>>b/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> new file mode 100644
>> index 000..0dfe242
>> --- /dev/null
>> +++ b/common/recipes-bsp/machinesetuptool/machinesetuptool_git.bb
>> @@ -0,0 +1,49 @@
>> +SUMMARY = "Daemon to setup an image for a specific machine at boot
>>time."
>> +SECTION = "base"
>> +LICENSE = "GPLv3"
>> +LIC_FILES_CHKSUM =
>>"file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
>> +RDEPENDS_${PN} = "sysvinit sed"
>> +
>> +PV = "1.0+git${SRCPV}"
>> +
>> +SRCREV = "4cb28ca5de3385f6e16a1e3f69b1a8a79b75ace4"
>> +
>> +SRC_URI = "git://git.yoctoproject.org/machinesetuptool.git"
>> +
>> +S = "${WORKDIR}/git"
>> +
>> +PACKAGE_ARCH = "${MACHINE_ARCH}"
>> +
>> +inherit autotools pkgconfig update-rc.d
>> +
>> +INITSCRIPT_NAME = "machinesetuptool"
>> +INITSCRIPT_PARAMS = "start 00 S . stop 20 0 1 6 ."
>> +
>> +RRECOMMENDS_${PN} += "kernel-module-uinput"
>> +
>> +python __anonymous () {
>> +src_uri = d.getVar('SRC_URI', True)
>> +machine_config_files = (d.getVar('MACHINE_CONFIG_FILES', True) or
>>"")
>> +for file in machine_config_files.split():
>> + src_uri += " file://" + file
>> +d.setVar('SRC_URI', src_uri)
>> +}
>> +
>> +do_install_append() {
>> +{
>> +echo SUPPORTED_MACHINES=\"${SUPPORTED_MACHINES}\"
>> +echo DEFAULT_MACHINE_SELECTION=${DEFAULT_MACHINE_SELECTION}
>> +} > ${D}/${sysconfdir}/${BPN}/defaults
>> +
>> +for file in ${MACHINE_CONFIG_FILES}
>> +do
>> +install -m 0644 ${S}/../${file} 
>> ${D}/${sysconfdir}/${BPN}/config/
>> +done
>> +}
>> +
>> +# following variables are initialized to empty values now.
>> +# These need to be populated with the desired machine configurations
>> +# for each BSP in it's own layer.
>> +MACHINE_CONFIG_FILES = ""
>> +SUPPORTED_MACHINES = ""
>> +DEFAULT_MACHINE_SELECTION = "none"
>
>

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

Re: [meta-intel] [PATCH 17/31] mohonpeak: add intel-ucode to MACHINE_FEATURES

[Kamble, Nitin A]

On 9/19/14, 6:43 AM, "Zanussi, Tom"  wrote:

>On Thu, 2014-09-18 at 17:35 -0700, nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> Enable the Intel microcode feature for this BSP.
>> 
>
>Are you sure ISG wants this enabled for all their BSPs?  In any case,
>we'll need an ack for each of the BSPs that you aren't the owner of.
>
>Thanks,
>
>Tom

Hi Rebecca, BL,

I would highly recommend the microcode feature enabled for IoTG BSPs. It
provides benefit of using latest microcode on the board CPUs, and uses the
production quality microcode published by Intel. And I do not expect any
issues caused by having the latest microcode on the systems. Can you
please Ack all the commits for IoTG BSPs? If for any reason your do not
want to use the latest microcode for any of the IoTG BSPs, let me know I
would like to understand the reasoning.

Thanks,
Nitin



>
>> Signed-off-by: Nitin A Kamble 
>> ---
>>  meta-isg/meta-mohonpeak/conf/machine/mohonpeak32.conf | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/meta-isg/meta-mohonpeak/conf/machine/mohonpeak32.conf
>>b/meta-isg/meta-mohonpeak/conf/machine/mohonpeak32.conf
>> index 32ded79..06e0b3d 100644
>> --- a/meta-isg/meta-mohonpeak/conf/machine/mohonpeak32.conf
>> +++ b/meta-isg/meta-mohonpeak/conf/machine/mohonpeak32.conf
>> @@ -16,6 +16,7 @@ XSERVER ?= "${XSERVER_X86_BASE} \
>> "
>>  
>>  MACHINE_FEATURES += "pcbios efi"
>> +MACHINE_FEATURES += "intel-ucode"
>>  
>>  SYSLINUX_OPTS = "serial 1 115200"
>>  SERIAL_CONSOLE = "115200 ttyS1"
>
>

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

Re: [meta-intel] [PATCH 04/31] intel-ucode: a new MACHINE_FEATURE for meta-intel BSPs

[Kamble, Nitin A]

On 9/19/14, 6:40 AM, "Zanussi, Tom"  wrote:

>On Thu, 2014-09-18 at 17:35 -0700, nitin.a.kam...@intel.com wrote:
>> From: Nitin A Kamble 
>> 
>> The Intel microcode can be enabled or disabled for each of the BSP by
>> using the MACHINE_FEATURES variable.
>>  All the BSPs which can utilize the feature need a line like this
>> in their machine configuration file.
>> 
>> MACHINE_FEATURES += "intel-ucode"
>> 
>
>As a new user-visible feature, this should have documentation, and in
>fact, users have already asked you for an explanation of what this
>microcode thing is and why they need it, and more importantly, under
>what conditions they might not want it or if there are any risks
>involved.

What kind of documentation are you looking for here? As this is specific
to meta-intel layer and BSPs, the generic BSP developer¹s manual is not
the right place for this.
Is there documentation of any other feature which can be looked at as an
example?

Thanks,
Nitin

>
>Thanks,
>
>Tom
>
>> Signed-off-by: Nitin A Kamble 
>> ---
>>  conf/machine/include/meta-intel.inc | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/conf/machine/include/meta-intel.inc
>>b/conf/machine/include/meta-intel.inc
>> index f43903e..b94e1dd 100644
>> --- a/conf/machine/include/meta-intel.inc
>> +++ b/conf/machine/include/meta-intel.inc
>> @@ -22,8 +22,8 @@ XSERVER_X86_ASPEED_AST = "xf86-video-ast \
>> "
>>  
>>  # include the user space intel microcode loading support in the
>>generated images.
>> -MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = " intel-microcode
>>iucode-tool"
>> +MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append =
>>"${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', '
>>intel-microcode iucode-tool', '', d)}"
>>  
>> -# For the early boot time kernel microcode loading support,
>> +# for the early boot time kernel microcode loading support,
>>  # merge the microcode data in the final initrd image.
>> -INITRD_prepend = "${DEPLOY_DIR_IMAGE}/microcode.cpio "
>> +INITRD_prepend = "${@bb.utils.contains('MACHINE_FEATURES',
>>'intel-ucode', '${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"
>
>

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

Re: [meta-intel] [PATCH 2/2] meta-intel.inc: allow disabling of Intel microcode

[Kamble, Nitin A]

On 9/18/14, 9:13 AM, "Hart, Darren"  wrote:

>On 9/17/14, 13:51, "Kamble, Nitin A"  wrote:
>
>>>The problem with this of course is we can't use it easily with the
>>>common
>>>BSPs and ultimately we want to eliminate as many of the other BSPs as
>>>possible.
>>>
>>>What is the exact issue with microcode? How does it break certain
>>>systems
>>>when enabled on the intel common BSPs?
>>
>>1st there is no boot issue related to microcode. What was reported is a
>>build issue. His initrd file was not built correctly. And we believe that
>>it happened because he used older version of poky/oecore. So that is
>>turning out to be a build setup issue.
>>
>>Here are the updates on the bug:
>>https://bugzilla.yoctoproject.org/show_bug.cgi?id=6730
>>
>>
>>Nitin
>
>Oh great!
>
>So what's the status of this then? Can it be enabled by default?


I see no blockage for enabling by default. But usages like microyocto may
want to disable the feature to save some space. So I am working on make
the the intel microcode feature available as a machine feature, and all
the machines in meta-intel will include the machine feature.

Nitin
 

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

Re: [meta-intel] [PATCH 1/2] intel-corei7-64.conf: include the AMT daemon in the images

[Kamble, Nitin A]

On 9/17/14, 12:58 PM, "Hart, Darren"  wrote:

>On 9/17/14, 12:44, "Kamble, Nitin A"  wrote:
>
>>From: Nitin A Kamble 
>>
>>Some of the platforms supported by the intel-corei7-64 BSP have AMT
>>feature
>>on the platform. Enable it so that it can get utilized with this BSP.
>
>How does this impact boot of systems without AMT support? 32 and 64 bit?

This change just adds the AMT module to the images. It would not affect
booting unless a system has broken AMT firmware. In that case the
machine-setup-tool configuration can be used to blacklist the mei kernel
driver.

Nitin

>
>>
>>Signed-off-by: Nitin A Kamble 
>>---
>> conf/machine/intel-corei7-64.conf | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>diff --git a/conf/machine/intel-corei7-64.conf
>>b/conf/machine/intel-corei7-64.conf
>>index c3b08bc..97d57b3 100644
>>--- a/conf/machine/intel-corei7-64.conf
>>+++ b/conf/machine/intel-corei7-64.conf
>>@@ -16,7 +16,7 @@ MACHINE_FEATURES += "wifi 3g"
>> 
>> MACHINE_HWCODECS ?= "va-intel gst-va-intel"
>> 
>>-MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"
>>+MACHINE_EXTRA_RRECOMMENDS += "linux-firmware lms8"
>> 
>> XSERVER ?= "${XSERVER_X86_BASE} \
>> ${XSERVER_X86_EXT} \
>>-- 
>>1.8.1.4
>>
>>
>
>
>-- 
>Darren HartOpen Source Technology Center
>darren.h...@intel.com  Intel Corporation
>
>

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

Re: [meta-intel] [PATCH 2/2] meta-intel.inc: allow disabling of Intel microcode

[Kamble, Nitin A]

>
>
>
>The problem with this of course is we can't use it easily with the common
>BSPs and ultimately we want to eliminate as many of the other BSPs as
>possible.
>
>What is the exact issue with microcode? How does it break certain systems
>when enabled on the intel common BSPs?

1st there is no boot issue related to microcode. What was reported is a
build issue. His initrd file was not built correctly. And we believe that
it happened because he used older version of poky/oecore. So that is
turning out to be a build setup issue.

Here are the updates on the bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6730


Nitin

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

Re: [meta-intel] [PATCH 2/2] meta-intel.inc: allow disabling of Intel microcode

[Kamble, Nitin A]

>
>No, we had this discussion. These BSPs need to build out of the box
>without special flags to disable feature that would otherwise break it on
>supported systems. If Microcode can't be enabled generically and safely,
>then it needs to be opt-in, not opt-out.
>
>--
>Darren
We discussed this a bit on jabber. The new proposal is to make it a
MACHINE_FEATURE and add it to all the machine .conf files from meta-intel.
BTW the valley island issue is something else, it is building fine for me,
but not for him. So there is no real known issue with the ucode feature
there.


Nitin


>

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

Re: [meta-intel] [PATCH 2/2] meta-intel.inc: allow disabling of Intel microcode

[Kamble, Nitin A]

>>
>
>I agree with Tom here - microcode should be opt-in at the machine level.
>
>Ross

Then it can be implemented as a MACHINE_FEATURE. Tom¹s need is bit
different though. He want it kind of a distro feature, so that poky-tiny
will not pick it up.

Nitin

>

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

Re: [meta-intel] [PATCH 2/2] meta-intel.inc: allow disabling of Intel microcode

[Kamble, Nitin A]

Tom,
  There is an issue with this commit. I will send another commit for this
purpose.

Thanks,
Nitin


On 9/17/14, 12:44 PM, "Kamble, Nitin A"  wrote:

>From: Nitin A Kamble 
>
>As per request from Tom, allow disabling of the Intel microcode
>feature for meta-intel BSPs.
>
>If one adds this line to local.conf while build a meta-intel BSP,
>the microcode feature will be disabled for the build target.
>
>DISABLE_INTEL_MICROCODE = "1"
>
>Signed-off-by: Nitin A Kamble 
>---
> conf/machine/include/meta-intel.inc | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
>diff --git a/conf/machine/include/meta-intel.inc
>b/conf/machine/include/meta-intel.inc
>index f43903e..e8134a7 100644
>--- a/conf/machine/include/meta-intel.inc
>+++ b/conf/machine/include/meta-intel.inc
>@@ -20,10 +20,11 @@ XSERVER_X86_MATROX_MGA = "xf86-video-mga \
> 
> XSERVER_X86_ASPEED_AST = "xf86-video-ast \
>"
>-
>+# if not disabled,
> # include the user space intel microcode loading support in the
>generated images.
>-MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = " intel-microcode iucode-tool"
>+MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = "${@[' intel-microcode
>iucode-tool', ''][d.getVar('DISABLE_INTEL_MICROCODE', True) != '1']}"
> 
>-# For the early boot time kernel microcode loading support,
>+# if not disabled,
>+# for the early boot time kernel microcode loading support,
> # merge the microcode data in the final initrd image.
>-INITRD_prepend = "${DEPLOY_DIR_IMAGE}/microcode.cpio "
>+INITRD_prepend = "${@['${DEPLOY_DIR_IMAGE}/microcode.cpio ',
>''][d.getVar('DISABLE_INTEL_MICROCODE', True) != '1']}"
>-- 
>1.8.1.4
>

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

Re: [meta-intel] [PATCH V2 3/3] meta-romley: DPDK v1.7.0 support for Romley machine config

[Kamble, Nitin A]

Hi Sreeju,

Aren¹t there other BSPs such as crystalforest which can utilize the DPDK
feature?

Nitin


On 9/17/14, 7:20 AM, "sreeju.armughanx.selva...@intel.com"
 wrote:

>From: Sreeju Selvaraj 
>
>Added MACHINE_EXTRA_RRECOMMENDS to include dpdk v1.7.0 support
>for romley machiine, so that dpdk will be enabled by default
>for Romley. Also included the dpdk example package, so that
>user can use example apps to exercise the DPDK libraries.
>
>Signed-off-by: Sreeju Selvaraj 
>---
> meta-romley/conf/machine/romley-ivb.conf | 4 
> meta-romley/conf/machine/romley.conf | 5 +
> 2 files changed, 9 insertions(+)
>
>diff --git a/meta-romley/conf/machine/romley-ivb.conf
>b/meta-romley/conf/machine/romley-ivb.conf
>index af52897..e130068 100644
>--- a/meta-romley/conf/machine/romley-ivb.conf
>+++ b/meta-romley/conf/machine/romley-ivb.conf
>@@ -18,3 +18,7 @@ XSERVER ?= "${XSERVER_X86_BASE} \
>${XSERVER_X86_EXT} \
>  ${XSERVER_X86_MATROX_MGA} \
>"
>+PREFERRED_VERSION_dpdk ?= "1.7.0%"
>+MACHINE_EXTRA_RRECOMMENDS += "dpdk \
>+dpdk-examples \
>+"
>diff --git a/meta-romley/conf/machine/romley.conf
>b/meta-romley/conf/machine/romley.conf
>index ed52a1e..a814fc3 100644
>--- a/meta-romley/conf/machine/romley.conf
>+++ b/meta-romley/conf/machine/romley.conf
>@@ -18,3 +18,8 @@ XSERVER ?= "${XSERVER_X86_BASE} \
>${XSERVER_X86_EXT} \
>  ${XSERVER_X86_MATROX_MGA} \
>"
>+PREFERRED_VERSION_dpdk ?= "1.7.0%"
>+MACHINE_EXTRA_RRECOMMENDS += "dpdk \
>+dpdk-examples \
>+"
>+
>-- 
>1.9.1
>
>-- 
>___
>meta-intel mailing list
>meta-intel@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/meta-intel

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

Re: [meta-intel] (no subject)

[Kamble, Nitin A]

HI Stuart,
  Can you give these details of the issue?


  *   Build configuration: any changes done to build setup other than setting 
MACHINE=valleyisland-32
  *   Does this issue happen on valleyisland-64 system?
  *   Explain what do you mean by initrd was not included?
  *

You can provide these details on the bug Tom created, so that the bug keeps all 
the context:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6730

Thanks,
Nitin


From: Stuart Weaver 
mailto:stuart.wea...@datapath.co.uk>>
Date: Tuesday, September 16, 2014 at 4:35 AM
To: "meta-intel@yoctoproject.org" 
mailto:meta-intel@yoctoproject.org>>
Subject: [meta-intel] (no subject)

Hi all,

I've just made a fresh Yocto/meta-intel repository and created an image based 
on core-image-sato for valleyisland-32. However when booting, the kernel was 
panicking as it could not load /initrd. Looking at the image created I found 
that initrd was not being included. After comparing with an older version of 
the repositories I had, I found that commenting out the following lines in 
meta-intel/conf/machine/include/meta-intel.inc solved the issue:

# include the user space intel microcode loading support in the generated 
images.
# MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = " intel-microcode iucode-tool"

# For the early boot time kernel microcode loading support,
# merge the microcode data in the final initrd image.
# INITRD_prepend = "${DEPLOY_DIR_IMAGE}/microcode.cpio "

I don't know anything bout intel microcode, and hence would it be possible to 
explain/point me to some place that has more information about the microcode 
and how to configure it to create the initrd correctly?

Best Regards,
Stuart

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 2/3] meta-intel/common: Upgrade DPDK to v1.7.0

[Kamble, Nitin A]

On 9/5/14, 1:11 AM, "sreeju.armughanx.selva...@intel.com"
 wrote:

>From: Sreeju Selvaraj 
>
>Added support for DPDK v1.7.0
>
>Building of example apps dpdk_qat and vhost failed due to dependancy on
>qat source and fuse libraries, so created patch to exclude the
>compilation of these examples.

Hi Sreeju,

Why not add dependency recipes to get it fully functional?

Nitin

>
>Resolved the installation failure found in example app ip_pipeline
>by cherry picking the patch from dpdk.org
>
>Resolved the test failure found with example app ring_pmd_autotest
>by cherry picking the patches from dpdk.org
>
>Signed-off-by: Sreeju Selvaraj 
>---
> ...exclude-compilation-of-dpdk_qat-and-vhost.patch |  40 +++
> ...examples-pipeline-build-with-all-examples.patch |  33 ++
> ...e-extra-devices-creation-with-vdev-option.patch |  43 +++
> .../dpdk/dpdk-1.7.0-ring-simplify-unit-tests.patch | 379
>+
> common/recipes-extended/dpdk/dpdk_1.7.0.bb |  27 ++
> 5 files changed, 522 insertions(+)
> create mode 100644
>common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-examples-exclude-compilation-
>of-dpdk_qat-and-vhost.patch
> create mode 100644
>common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-examples-pipeline-build-with-
>all-examples.patch
> create mode 100644
>common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-ring-remove-extra-devices-cre
>ation-with-vdev-option.patch
> create mode 100644
>common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-ring-simplify-unit-tests.patc
>h
> create mode 100644 common/recipes-extended/dpdk/dpdk_1.7.0.bb
>
>diff --git 
>a/common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-examples-exclude-compilatio
>n-of-dpdk_qat-and-vhost.patch
>b/common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-examples-exclude-compilatio
>n-of-dpdk_qat-and-vhost.patch
>new file mode 100644
>index 000..9a9f0c0
>--- /dev/null
>+++ 
>b/common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-examples-exclude-compilatio
>n-of-dpdk_qat-and-vhost.patch
>@@ -0,0 +1,40 @@
>+From f43e001c7b47226f443abaf5e7690971fbf27d10 Mon Sep 17 00:00:00 2001
>+From: Sreeju Selvaraj 
>+Date: Fri, 5 Sep 2014 10:04:34 +0800
>+Subject: [PATCH] examples: exclude compilation of dpdk_qat and vhost
>+
>+example apps dpdk_qat and vhost have dependency on qat source
>+and fuse libraries which causes compilation error.
>+There is a new global Makefile for examples added in dpdk v1.7.0
>+So mute the compilation of these apps there.
>+
>+Signed-off-by: Sreeju Selvaraj 
>+---
>+ examples/Makefile | 4 
>+ 1 file changed, 4 deletions(-)
>+
>+diff --git a/examples/Makefile b/examples/Makefile
>+index dc85cf3..2127458 100644
>+--- a/examples/Makefile
> b/examples/Makefile
>+@@ -38,9 +38,6 @@ RTE_TARGET ?= x86_64-native-linuxapp-gcc
>+ include $(RTE_SDK)/mk/rte.vars.mk
>+ 
>+ DIRS-y += cmdline
>+-ifneq ($(ICP_ROOT),)
>+-DIRS-y += dpdk_qat
>+-endif
>+ DIRS-y += exception_path
>+ DIRS-y += helloworld
>+ DIRS-y += ip_pipeline
>+@@ -62,7 +59,6 @@ DIRS-$(CONFIG_RTE_LIBRTE_METER) += qos_meter
>+ DIRS-$(CONFIG_RTE_LIBRTE_SCHED) += qos_sched
>+ DIRS-y += quota_watermark
>+ DIRS-y += timer
>+-DIRS-y += vhost
>+ DIRS-$(CONFIG_RTE_LIBRTE_XEN_DOM0) += vhost_xen
>+ DIRS-y += vmdq
>+ DIRS-y += vmdq_dcb
>+-- 
>+1.9.1
>+
>diff --git 
>a/common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-examples-pipeline-build-wit
>h-all-examples.patch
>b/common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-examples-pipeline-build-wit
>h-all-examples.patch
>new file mode 100644
>index 000..234260b
>--- /dev/null
>+++ 
>b/common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-examples-pipeline-build-wit
>h-all-examples.patch
>@@ -0,0 +1,33 @@
>+From 835b75b7b22d8373f6ee17cb9ff456518ea7c208 Mon Sep 17 00:00:00 2001
>+From: Thomas Monjalon 
>+Date: Thu, 17 Jul 2014 10:30:52 +0200
>+Subject: [PATCH] examples/pipeline: build with all examples
>+
>+Imported patch from: http://dpdk.org/browse/dpdk/log/
>+
>+When adding this packet framework sample (commit 77a3346),
>+it has been forgotten to add it into the global makefile for
>+"make examples".
>+
>+Signed-off-by: Thomas Monjalon 
>+(cherry picked from commit a6664a09a7caa5e63f9ae625cf1946b0eef7794e)
>+Signed-off-by: Sreeju Selvaraj 
>+---
>+ examples/Makefile | 1 +
>+ 1 file changed, 1 insertion(+)
>+
>+diff --git a/examples/Makefile b/examples/Makefile
>+index d0624f6..dc85cf3 100644
>+--- a/examples/Makefile
> b/examples/Makefile
>+@@ -43,6 +43,7 @@ DIRS-y += dpdk_qat
>+ endif
>+ DIRS-y += exception_path
>+ DIRS-y += helloworld
>++DIRS-y += ip_pipeline
>+ DIRS-y += ip_reassembly
>+ DIRS-$(CONFIG_RTE_MBUF_SCATTER_GATHER) += ip_fragmentation
>+ DIRS-$(CONFIG_RTE_MBUF_SCATTER_GATHER) += ipv4_multicast
>+-- 
>+1.9.1
>+
>diff --git 
>a/common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-ring-remove-extra-devices-c
>reation-with-vdev-option.patch
>b/common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-ring-remove-extra-devices-c
>reation-with-vdev-option.patch
>new file mode 100644
>index 000..02322b3
>--- /dev/null
>+++ 
>b/common/recipes-extended/dpdk/dpdk/dpdk-1.7.0-ring-remove-extra

Re: [meta-intel] [PATCH 1/1] meta-valleyisland: Update linux-yocto v3.10 recipes SRCREV to v3.10.43

[Kamble, Nitin A]

Acked-By: Nitin A Kamble 


On 9/8/14, 4:16 AM, "rebecca.swee.fun.ch...@intel.com"
 wrote:

>From: Chang Rebecca Swee Fun 
>
>Use the latest HEADs of the git branches from the linux-yocto
>v3.10 kernel repository.
>
>Signed-off-by: Chang Rebecca Swee Fun 
>---
> .../recipes-kernel/linux/linux-yocto_3.10.bbappend | 24
>+++---
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
>diff --git 
>a/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappen
>d 
>b/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappen
>d
>index 7e7f05f..dbc01a5 100644
>--- 
>a/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappen
>d
>+++ 
>b/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappen
>d
>@@ -6,15 +6,15 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> COMPATIBLE_MACHINE_valleyisland-32 = "valleyisland-32"
> KMACHINE_valleyisland-32 = "valleyisland-32"
> KBRANCH_valleyisland-32 = "standard/base"
>-KERNEL_FEATURES_valleyisland-32 = "
>features/valleyisland-io/valleyisland-io \
>+KERNEL_FEATURES_valleyisland-32 = "
>features/valleyisland-io/valleyisland-io.scc \
>   
> features/valleyisland-io/valleyisland-io-pci.scc"
> 
>-LINUX_VERSION_valleyisland-32 = "3.10.40"
>-SRCREV_machine_valleyisland-32 =
>"f53a6114b3a6e8c03ca4752de829887015f4c942"
>-SRCREV_meta_valleyisland-32 = "90edb289dccfe838d4e364e1a5815447a6642b98"
>-SRCREV_valleyisland-io_valleyisland-32 =
>"8ea4fb625f2654bbdd5dfcb9db67328d21ebe504"
>+LINUX_VERSION_valleyisland-32 = "3.10.43"
>+SRCREV_machine_valleyisland-32 =
>"e4f08d724d6663e6d23d19668c97f9e6792c94d2"
>+SRCREV_meta_valleyisland-32 = "fab23a4d44de25ee77e497cbf8605eadc3aaf3d8"
>+SRCREV_valleyisland-io_valleyisland-32 =
>"0992d01f5f382f6da60004ef87f67ebd3ca13732"
> 
>-SRC_URI_valleyisland-32 =
>"git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1
>;branch=${KBRANCH},${KMETA},valleyisland-io-1.0;name=machine,meta,valleyis
>land-io"
>+SRC_URI_valleyisland-32 =
>"git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1
>;branch=${KBRANCH},${KMETA},valleyisland-io-3.0;name=machine,meta,valleyis
>land-io"
> 
> #
> # MACHINE = valleyisland-64 #
>@@ -22,15 +22,15 @@ SRC_URI_valleyisland-32 =
>"git://git.yoctoproject.org/linux-yocto-3.10.git;proto
> COMPATIBLE_MACHINE_valleyisland-64 = "valleyisland-64"
> KMACHINE_valleyisland-64 = "valleyisland"
> KBRANCH_valleyisland-64 = "standard/base"
>-KERNEL_FEATURES_valleyisland-64 = "
>features/valleyisland-io/valleyisland-io \
>+KERNEL_FEATURES_valleyisland-64 = "
>features/valleyisland-io/valleyisland-io.scc \
>   
> features/valleyisland-io/valleyisland-io-pci.scc"
> 
>-LINUX_VERSION_valleyisland-64 = "3.10.40"
>-SRCREV_machine_valleyisland-64 =
>"f53a6114b3a6e8c03ca4752de829887015f4c942"
>-SRCREV_meta_valleyisland-64 = "90edb289dccfe838d4e364e1a5815447a6642b98"
>-SRCREV_valleyisland-io_valleyisland-64 =
>"8ea4fb625f2654bbdd5dfcb9db67328d21ebe504"
>+LINUX_VERSION_valleyisland-64 = "3.10.43"
>+SRCREV_machine_valleyisland-64 =
>"e4f08d724d6663e6d23d19668c97f9e6792c94d2"
>+SRCREV_meta_valleyisland-64 = "fab23a4d44de25ee77e497cbf8605eadc3aaf3d8"
>+SRCREV_valleyisland-io_valleyisland-64 =
>"0992d01f5f382f6da60004ef87f67ebd3ca13732"
> 
>-SRC_URI_valleyisland-64 =
>"git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1
>;branch=${KBRANCH},${KMETA},valleyisland-io-1.0;name=machine,meta,valleyis
>land-io"
>+SRC_URI_valleyisland-64 =
>"git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1
>;branch=${KBRANCH},${KMETA},valleyisland-io-3.0;name=machine,meta,valleyis
>land-io"
> 
> KERNEL_MODULE_AUTOLOAD_append_valleyisland-32 = " i2c-dev"
> KERNEL_MODULE_AUTOLOAD_append_valleyisland-64 = " i2c-dev"
>-- 
>1.9.1
>
>-- 
>___
>meta-intel mailing list
>meta-intel@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/meta-intel

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

Re: [meta-intel] [Patch v5 0/5] microcode loading support for Intel BSPs

[Kamble, Nitin A]

> -Original Message-
> From: Zanussi, Tom
> Sent: Wednesday, September 03, 2014 8:04 PM
> To: Kamble, Nitin A
> Cc: Hart, Darren; Burton, Ross; meta-intel@yoctoproject.org
> Subject: Re: [Patch v5 0/5] microcode loading support for Intel BSPs
> 
> On Fri, 2014-08-29 at 10:22 -0700, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > Enable microcode loading support for the Intel BSPs. The required
> > piece of supporting more than one file systems in the INITRD
> > defination is already pulled in the oecore layer.
> >
> 
> Hmm, seeing some build problems here:

Interesting, this problem did not happen with the core-image-sato image. Looks 
like somehow the microcode.cpio file is getting deleted for the minimal image. 
I need to dig further.

Nitin

> 
> ERROR: Function failed: build_hddimg (log file is located at
> /home/trz/yocto/master-cur/build/tmp/work/intel_corei7_64-poky-
> linux/core-image-minimal/1.0-r0/temp/log.do_bootimg.12866)
> ERROR: Logfile of failure stored in: /home/trz/yocto/master-
> cur/build/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-
> r0/temp/log.do_bootimg.12866
> Log data follows:
> | DEBUG: Executing python function do_bootimg
> | DEBUG: Executing python function build_syslinux_cfg
> | DEBUG: Python function build_syslinux_cfg finished
> | DEBUG: Executing python function build_efi_cfg
> | DEBUG: Python function build_efi_cfg finished
> | DEBUG: Executing shell function build_hddimg
> | ERROR: /home/trz/yocto/master-cur/build/tmp/deploy/images/intel-
> corei7-64/microcode.cpio is invalid. initrd image creation failed.
> | WARNING: /home/trz/yocto/master-cur/build/tmp/work/intel_corei7_64-
> poky-linux/core-image-minimal/1.0-r0/temp/run.build_hddimg.12866:1 exit
> 1 from
> |   exit 1
> | DEBUG: Python function do_bootimg finished
> | ERROR: Function failed: build_hddimg (log file is located at
> | /home/trz/yocto/master-cur/build/tmp/work/intel_corei7_64-poky-
> linux/c
> | ore-image-minimal/1.0-r0/temp/log.do_bootimg.12866)
> ERROR: Task 8 (/home/trz/yocto/master-cur/meta/recipes-
> core/images/core-image-minimal.bb, do_bootimg) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 3134 tasks of which 698 didn't need to be
> rerun and 1 failed.
> Waiting for 0 running tasks to finish:
> 
> Summary: 1 task failed:
>   /home/trz/yocto/master-cur/meta/recipes-core/images/core-image-
> minimal.bb, do_bootimg
> Summary: There were 32 WARNING messages shown.
> Summary: There was 1 ERROR message shown, returning a non-zero exit
> code.
> 
> 
> Build Configuration:
> BB_VERSION= "1.23.1"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "Fedora-19"
> TARGET_SYS= "x86_64-poky-linux"
> MACHINE   = "intel-corei7-64"
> DISTRO= "poky"
> DISTRO_VERSION= "1.6+snapshot-20140903"
> TUNE_FEATURES = "m64 corei7"
> TARGET_FPU= ""
> meta
> meta-yocto
> meta-yocto-bsp= "master34:a44006262cf3b810ec78b4cccd8076102a7a0f3e"
> meta-intel= "master31:398a16c1abe1dc86d4889579fea15ce0392b2721"
> 
> 
> > Thanks,
> > Nitin
> >
> >
> > The following changes since commit
> 00de64dbe0563dfaf21679e2902a56f62a039df4:
> >
> >   meta-crystalforest: Update README with new build settings
> > (2014-08-27 11:44:11 -0500)
> >
> > are available in the git repository at:
> >
> >   git://git.yoctoproject.org/meta-intel-contrib nitin/misc
> >
> > http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin/m
> > isc
> >
> > Nitin A Kamble (5):
> >   meta-intel BSPs: include meta-intel.inc
> >   iucode-tool: a new recipe for loading Intel CPU microcode
> >   intel-microcode: a recipe for Intel microcode datafile
> >   meta-intel BSPs: enable microcode loading support for images
> >   use the INITRD list mechanism for early microcode loading
> >
> >  common/custom-licenses/Intel-Microcode-License | 123
> +
> >  .../microcode/intel-microcode_20140624.bb  |  52 +
> >  common/recipes-core/microcode/iucode-tool_1.0.2.bb |  25 +
> >  conf/machine/include/meta-intel.inc|   6 +
> >  meta-crownbay/conf/machine/crownbay-noemgd.conf|   1 +
> >  meta-emenlow/conf/machine/emenlow-noemgd.conf  |   1 +
> >  meta-fri2/conf/machine/fri2-noemgd.conf|   1 +
> >  meta-jasperforest/conf/machine/jasperforest.conf   |   1 +
> >  meta-nuc/conf/machine/nuc.conf |   1 +
> >  meta-sugarbay/conf/machine/sugarbay.conf   |   1 +
> >  10 files changed, 212 insertions(+)
> >  create mode 100644 common/custom-licenses/Intel-Microcode-License
> >  create mode 100644
> > common/recipes-core/microcode/intel-microcode_20140624.bb
> >  create mode 100644 common/recipes-core/microcode/iucode-
> tool_1.0.2.bb
> >
> 

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

Re: [meta-intel] [Patch v5 5/5] use the INITRD list mechanism for early microcode loading

[Kamble, Nitin A]

> >
> 
> How is this the case? In 3/5, the new recipe includes the line:
> 
> +LICENSE = "Intel-Microcode-License"
> 
> 
> So, how is it the license does not need to be whitelisted?


What is listed in the LICENSE_FLAGS variable need to be whitelisted. The 
LICENSE is a required variable for every recipe.


Thanks,
Nitin


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

Re: [meta-intel] [Patch v5 5/5] use the INITRD list mechanism for early microcode loading

[Kamble, Nitin A]

> 
> Hrm... I confess I forget where we left this. Do we not need the enabled
> condition? What happens if you try to build images for meta-intel systems
> without the meta-intel license whitelisted? My understanding is that those
> recipes still need to parse, but that will fail if the license requirements 
> are not
> met.

The recipe does not need the whitelisted license anymore. It is similar to the 
linux-firmware recipe now.
So no checks are necessary anymore.

Nitin
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [Patch v5 3/5] intel-microcode: a recipe for Intel microcode datafile

[Kamble, Nitin A]

> > The plan is to get the microcode delivered through the linux-firmware
> repository. But it is taking time for that to happen. So until that happens we
> use the intel-microcode recipe. And once the Intel microcode is available
> through the linux-firmware repository, then the intel-microcode recipe will
> be replaced by extensions to the linux-firmware recipe.
> >
> 
> OK, thanks for the explanation.  Would you mind updating the bug with that
> information?
> 
> Thanks,
> 
> Tom

Done
Nitin
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [Patch v5 3/5] intel-microcode: a recipe for Intel microcode datafile

[Kamble, Nitin A]

> -Original Message-
> From: Zanussi, Tom
> Sent: Tuesday, September 02, 2014 8:43 AM
> To: Kamble, Nitin A
> Cc: Hart, Darren; Burton, Ross; meta-intel@yoctoproject.org
> Subject: Re: [Patch v5 3/5] intel-microcode: a recipe for Intel microcode
> datafile
> 
> On Fri, 2014-08-29 at 10:22 -0700, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > This recipe provides the microcode datafile for Intel Processors.
> >
> > The recipe provides:
> >  1. microcode.dat file for microcode updating from user space with the
> > iucode-tool utility.
> >  2. the microcode cpio file which gets bundled with the initrd to support
> > microcode loading at early boot time.
> >
> > [ YOCTO #5114 ]
> >
> 
> The last entry in this bug says that the microcode recipe can go away, so why
> is this needed?
> 


The plan is to get the microcode delivered through the linux-firmware 
repository. But it is taking time for that to happen. So until that happens we 
use the intel-microcode recipe. And once the Intel microcode is available 
through the linux-firmware repository, then the intel-microcode recipe will be 
replaced by extensions to the linux-firmware recipe.

Nitin

> Tom
> 
> > Signed-off-by: Ross Burton 
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  common/custom-licenses/Intel-Microcode-License | 123
> +
> >  .../microcode/intel-microcode_20140624.bb  |  52 +
> >  2 files changed, 175 insertions(+)
> >  create mode 100644 common/custom-licenses/Intel-Microcode-License
> >  create mode 100644
> > common/recipes-core/microcode/intel-microcode_20140624.bb
> >
> > diff --git a/common/custom-licenses/Intel-Microcode-License
> > b/common/custom-licenses/Intel-Microcode-License
> > new file mode 100644
> > index 000..af5b41c
> > --- /dev/null
> > +++ b/common/custom-licenses/Intel-Microcode-License
> > @@ -0,0 +1,123 @@
> > +INTEL SOFTWARE LICENSE AGREEMENT
> > +
> > +IMPORTANT - READ BEFORE COPYING, INSTALLING OR USING.
> > +Do not use or load this software and any associated materials
> > +(collectively, the "Software") until you have carefully read the
> > +following terms and conditions. By loading or using the Software, you
> > +agree to the terms of this Agreement. If you do not wish to so agree, do
> not install or use the Software.
> > +
> > +LICENSES: Please Note:
> > +- If you are a network administrator, the "Site License" below shall
> > +apply to you.
> > +- If you are an end user, the "Single User License" shall apply to you.
> > +- If you are an original equipment manufacturer (OEM), the "OEM
> License"
> > +shall apply to you.
> > +
> > +SITE LICENSE. You may copy the Software onto your organization's
> > +computers for your organization's use, and you may make a reasonable
> > +number of back-up copies of the Software, subject to these conditions:
> > +
> > +1. This Software is licensed for use only in conjunction with Intel
> > +component products. Use of the Software in conjunction with non-Intel
> > +component products is not licensed hereunder.
> > +2. You may not copy, modify, rent, sell, distribute or transfer any
> > +part of the Software except as provided in this Agreement, and you
> > +agree to prevent unauthorized copying of the Software.
> > +3. You may not reverse engineer, decompile, or disassemble the
> Software.
> > +4. You may not sublicense or permit simultaneous use of the Software
> > +by more than one user.
> > +5. The Software may include portions offered on terms in addition to
> > +those set out here, as set out in a license accompanying those portions.
> > +
> > +SINGLE USER LICENSE. You may copy the Software onto a single computer
> > +for your personal, noncommercial use, and you may make one back-up
> > +copy of the Software, subject to these conditions:
> > +
> > +1. This Software is licensed for use only in conjunction with Intel
> > +component products. Use of the Software in conjunction with non-Intel
> > +component products is not licensed hereunder.
> > +2. You may not copy, modify, rent, sell, distribute or transfer any
> > +part of the Software except as provided in this Agreement, and you
> > +agree to prevent unauthorized copying of the Software.
> > +3. You may not reverse engineer, decompile, or disassemble the
> Software.
> > +4. You may not sublicense or permit simultaneous use of the Software
> > +by more than one user.
> > +5. The Software may in

Re: [meta-intel] [Patch v5 5/5] use the INITRD list mechanism for early microcode loading

[Kamble, Nitin A]

> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Monday, September 01, 2014 8:39 AM
> To: Kamble, Nitin A
> Cc: Zanussi, Tom; Hart, Darren; meta-intel@yoctoproject.org
> Subject: Re: [Patch v5 5/5] use the INITRD list mechanism for early microcode
> loading
> 
> On 29 August 2014 18:22,   wrote:
> >  # if enabled, include user space intel microcode loading support in the
> generated images.
> >  MACHINE_EXTRA_RRECOMMENDS = "intel-microcode iucode-tool"
> > +
> > +# if enabled, use the microcode added initrd
> 
> I don't see any conditional tests for the "if enabled" part of the comment.
> 
> Ross

Good catch, I have fixed the comment on the contrib branch now.

Thanks,
Nitin


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

Re: [meta-intel] [PATCH] linux-yocto: Use _append when overrides are used

[Kamble, Nitin A]

> -Original Message-
> From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
> boun...@yoctoproject.org] On Behalf Of Josep Puigdemont
> Sent: Friday, August 29, 2014 1:53 AM
> To: Zanussi, Tom; meta-intel@yoctoproject.org
> Subject: [meta-intel] [PATCH] linux-yocto: Use _append when overrides are
> used
> 
> Some modules in the KERNEL_MODULE_AUTOLOAD list where removed
> when including the meta-intel layer. It turns out the problem happens due to
> using the += operator together with machine overrides. Using
> _append_machine fixes this.
> 
> Addresses bug:
> [YOCTO #6668]

The commit looks fine, although it may it hard to remove entries from 
KERNEL_MODULE_AUTOLOAD. The issue can also be fixed by making similar changes 
in the meta-virtualization layer 
(http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-kernel/linux/linux-yocto_3.14.bbappend).
 But there is no ideal solution here, so I am ok with the commit, few typos 
need to be corrected from the commit message though.

Thanks,
Nitin


> 
> Signed-off-by: Josep Puigdemont 
> ---
>  common/recipes-kernel/linux/linux-yocto-dev.bbappend  | 8 
> 
>  common/recipes-kernel/linux/linux-yocto_3.10.bbappend | 8 ---
> -
>  common/recipes-kernel/linux/linux-yocto_3.14.bbappend | 8 ---
> -
>  meta-fri2/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend   | 4 ++--
>  meta-fri2/recipes-kernel/linux/linux-yocto_3.10.bbappend  | 4 ++--
>  .../recipes-kernel/linux/linux-yocto_3.10.bbappend| 4 ++--
>  6 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/common/recipes-kernel/linux/linux-yocto-dev.bbappend
> b/common/recipes-kernel/linux/linux-yocto-dev.bbappend
> index bfb5f62..554bd62 100644
> --- a/common/recipes-kernel/linux/linux-yocto-dev.bbappend
> +++ b/common/recipes-kernel/linux/linux-yocto-dev.bbappend
> @@ -19,9 +19,9 @@ KERNEL_FEATURES_append_corei7-64-intel-common =
> "${KERNEL_FEATURES_INTEL_COMMON}  # default SRCREV is set and linux-
> yocto-dev is the preferred provider.
> 
>  # For Crystalforest and Romley
> -KERNEL_MODULE_AUTOLOAD_core2-32-intel-common += "uio"
> -KERNEL_MODULE_AUTOLOAD_corei7-64-intel-common += "uio"
> +KERNEL_MODULE_AUTOLOAD_append_core2-32-intel-common = " uio"
> +KERNEL_MODULE_AUTOLOAD_append_corei7-64-intel-common = " uio"
> 
>  # For FRI2, NUC
> -KERNEL_MODULE_AUTOLOAD_core2-32-intel-common += "iwlwifi"
> -KERNEL_MODULE_AUTOLOAD_corei7-64-intel-common += "iwlwifi"
> +KERNEL_MODULE_AUTOLOAD_append_core2-32-intel-common = " iwlwifi"
> +KERNEL_MODULE_AUTOLOAD_append_corei7-64-intel-common = "
> iwlwifi"
> diff --git a/common/recipes-kernel/linux/linux-yocto_3.10.bbappend
> b/common/recipes-kernel/linux/linux-yocto_3.10.bbappend
> index a142e5b..19af367 100644
> --- a/common/recipes-kernel/linux/linux-yocto_3.10.bbappend
> +++ b/common/recipes-kernel/linux/linux-yocto_3.10.bbappend
> @@ -21,9 +21,9 @@ KBRANCH_corei7-64-intel-common = "standard/base"
>  KERNEL_FEATURES_append_corei7-64-intel-common =
> "${KERNEL_FEATURES_INTEL_COMMON}"
> 
>  # For Crystalforest and Romley
> -KERNEL_MODULE_AUTOLOAD_core2-32-intel-common += "uio"
> -KERNEL_MODULE_AUTOLOAD_corei7-64-intel-common += "uio"
> +KERNEL_MODULE_AUTOLOAD_append_core2-32-intel-common = " uio"
> +KERNEL_MODULE_AUTOLOAD_append_corei7-64-intel-common = " uio"
> 
>  # For FRI2, NUC
> -KERNEL_MODULE_AUTOLOAD_core2-32-intel-common += "iwlwifi"
> -KERNEL_MODULE_AUTOLOAD_corei7-64-intel-common += "iwlwifi"
> +KERNEL_MODULE_AUTOLOAD_append_core2-32-intel-common = " iwlwifi"
> +KERNEL_MODULE_AUTOLOAD_append_corei7-64-intel-common = "
> iwlwifi"
> diff --git a/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
> b/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
> index a0ca5fc..b367adb 100644
> --- a/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
> +++ b/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
> @@ -20,9 +20,9 @@ KBRANCH_corei7-64-intel-common = "standard/base"
>  KERNEL_FEATURES_append_corei7-64-intel-common =
> "${KERNEL_FEATURES_INTEL_COMMON}"
> 
>  # For Crystalforest and Romley
> -KERNEL_MODULE_AUTOLOAD_core2-32-intel-common += "uio"
> -KERNEL_MODULE_AUTOLOAD_corei7-64-intel-common += "uio"
> +KERNEL_MODULE_AUTOLOAD_append_core2-32-intel-common = " uio"
> +KERNEL_MODULE_AUTOLOAD_append_corei7-64-intel-common = " uio"
> 
>  # For FRI2, NUC
> -KERNEL_MODULE_AUTOLOAD_core2-32-intel-common += "iwlwifi"
> -KERNEL_MODULE_AUTOLOAD_corei7-64-intel-common += "iwlwifi"
> +KERNEL_MODULE_AUTOLOAD_append_core2-32-intel-common = " iwlwifi"
> +KERNEL_MODULE_AUTOLOAD_append_corei7-64-intel-common = "
> iwlwifi"
> diff --git a/meta-fri2/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
> b/meta-fri2/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
> index e57449f..25361e8 100644
> --- a/meta-fri2/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
> +++ b/meta-fri2/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
> @@ -12,5 +12,5 @@ KBRA

Re: [meta-intel] [PATCH 0/2] meta-crystalforest: merge machine conf

[Kamble, Nitin A]

For the series.
Acked By: Nitin A Kamble 

Thanks,
Nitin


> -Original Message-
> From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
> boun...@yoctoproject.org] On Behalf Of
> rebecca.swee.fun.ch...@intel.com
> Sent: Friday, August 08, 2014 3:14 AM
> To: meta-intel@yoctoproject.org
> Subject: [meta-intel] [PATCH 0/2] meta-crystalforest: merge machine conf
> 
> From: Chang Rebecca Swee Fun 
> 
> Hi,
> 
> This patchset to merge machine conf files for both Crystal Forest Gladden
> and Server platforms. The second patch is about updating the README with
> new build settings.
> 
> Both crystal forest gladden and server platforms are currently sharing the
> same machine configurations maintained in different conf files. It makes
> more sense by merging the two similar conf files into one.
> 
> After introducing new conf file, the build settings for Crystal Forest needs 
> an
> update too. Bitbake will now taking MACHINE name as "crystalforest" and
> the image built will be able to boot on both supported platforms.
> 
> This patch set was built tested and booted up successfully on both Gladden
> and Server platforms. Some drivers sanity tests had been carried out to
> ensure image is in good condition.
> 
> Please review and push this patchset into meta-intel master and Daisy
> branch.
> 
> Thanks in advance.
> 
> Rebecca
> 
> The following changes since commit
> 7d9471578801d571ceca9e54bbdf22cb84284ff9:
> 
>   linux-yocto-dev: Remove LINUX_VERSION (2014-07-29 14:28:55 -0700)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/meta-intel-contrib rebeccas/crystalforest-dev
>   http://git.yoctoproject.org/cgit.cgi/meta-intel-
> contrib/log/?h=rebeccas/crystalforest-dev
> 
> Chan Wei Sern (1):
>   meta-crystalforest: Merge machine conf
> 
> Chang Rebecca Swee Fun (1):
>   meta-crystalforest: Update README with new build settings
> 
>  meta-crystalforest/README  | 22 ++-
>  .../conf/machine/crystalforest-server.conf | 33 
> --
>  ...ystalforest-gladden.conf => crystalforest.conf} | 13 +++--
>  3 files changed, 18 insertions(+), 50 deletions(-)  delete mode 100644 meta-
> crystalforest/conf/machine/crystalforest-server.conf
>  rename meta-crystalforest/conf/machine/{crystalforest-gladden.conf =>
> crystalforest.conf} (72%)
> 
> --
> 1.9.1
> 
> --
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [Patch v4 3/6] intel-microcode: a recipe for Intel microcode datafile

[Kamble, Nitin A]

> -Original Message-
> From: Darren Hart [mailto:dvh...@linux.intel.com]
> Sent: Tuesday, July 29, 2014 8:33 AM
> To: Burton, Ross
> Cc: Kamble, Nitin A; meta-intel@yoctoproject.org; Zanussi, Tom; Hart, Darren
> Subject: Re: [meta-intel] [Patch v4 3/6] intel-microcode: a recipe for Intel
> microcode datafile
> 
> On Mon, Jul 28, 2014 at 01:57:08PM +0100, Burton, Ross wrote:
> > On 25 July 2014 17:49, Kamble, Nitin A  wrote:
> > > Maybe we can wait for the intel microcode to go intoe linux-firmware,
> then this recipe will not be needed at all. But for that to happen intel-
> microcode needs to show up in the linux-firmware repo, and I will push on
> that instead of pushing this recipe.
> >
> > This seems like the path of least pain for us certainly.
> 
> What does this mean for this series? Is it on hold until such time as linux-
> firmware includes the necessary bins? Are we confident it will be updated
> frequently enough?

These are the open questions for now. And I am trying to find the responsible 
person for this effort to get answers.

Nitin

> 
> --
> Darren
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [Patch v4 4/6] image-ucode.bbclass: a new bbclass for initramfs images

[Kamble, Nitin A]

> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Monday, July 21, 2014 12:30 PM
> To: Kamble, Nitin A
> Cc: Zanussi, Tom; Hart, Darren; Purdie, Richard; meta-intel@yoctoproject.org
> Subject: Re: [Patch v4 4/6] image-ucode.bbclass: a new bbclass for initramfs
> images
> 
> On 19 July 2014 01:18,   wrote:
> > +IMAGE_TYPES += "cpio.gz.ucode"
> > +COMPRESSIONTYPES += "gz.ucode"
> > +COMPRESS_CMD_gz.ucode = "${COMPRESS_CMD_gz}; cat
> ${EARLY_UCODE_CPIO} ${IMAGE_NAME}.rootfs.${type}.gz >
> ${IMAGE_NAME}.rootfs.${type}.gz.ucode"
> > +COMPRESS_DEPENDS_gz.ucode = "${COMPRESS_DEPENDS_gz} intel-
> microcode"
> 
> Something about this has always bugged me and I just realised what it is.  As 
> I
> understand it the kernel allows an arbitrary number of cpio archives to be
> appended to the kernel, but our image creation code expects one.  This class
> is basically working around that limitation by being a specialised image type
> that appends another hard-coded file.
> 
> If the image creation code was changed to expect a list, then we wouldn't
> need this class at all but could simply do INITRD += $(EARLY_UCODE_CPIO).

As this change will be in oecore layer, adding oecore mailing list to this 
thread.

The INITRD variable is used at different places like grub-efi.bbclass, 
syslinux.bbclass, bootimg.bbclass, gummyboot.bbclass, boot-directdisk.bbclass, 
image-live.bbclass . So extending INITRD var is going to be bit invasive. Let 
me see if this can be handled in less invasive way.

Nitin
 
> 
> Ross
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [Patch v4 3/6] intel-microcode: a recipe for Intel microcode datafile

[Kamble, Nitin A]

This recipe is in current state marked as click-through license, needing a 
special license specified in LICENSE_FLAGS_WHITELIST var. In this state the 
recipe can not be enabled by default.

Also worth noting here is that,
  * This recipe is similar to linux-firmware recipe, which does not use the 
whitelist flags for license.
  * Linux distributions like redhat are enabling microcode loading without any 
special license agreement requirements
  * AMD is shipping microcode in the linux-firmware package
  * Intel microcode is also planned to be distributed through the 
linux-firmware repo. (https://fedorahosted.org/microcode_ctl/) I will ping 
internally who is responsible for it, as this is not happening as of now.

Maybe we can wait for the intel microcode to go intoe linux-firmware, then this 
recipe will not be needed at all. But for that to happen intel-microcode needs 
to show up in the linux-firmware repo, and I will push on that instead of 
pushing this recipe.

Thanks,
Nitin

> -Original Message-
> From: Kamble, Nitin A
> Sent: Friday, July 18, 2014 5:18 PM
> To: Zanussi, Tom; Hart, Darren; richard.pur...@linuxfoundation.org; Burton,
> Ross
> Cc: meta-intel@yoctoproject.org; Kamble, Nitin A
> Subject: [Patch v4 3/6] intel-microcode: a recipe for Intel microcode datafile
> 
> From: Nitin A Kamble 
> 
> This recipe provides the microcode datafile for Intel Processors.
> 
> The recipe provides:
>  1. microcode.dat file for microcode updating from user space with the
> iucode-tool utility.
>  2. the microcode cpio file which gets bundled with the initrd to support
> microcode loading at early boot time.
> 
> Note that this recipe has LICENSE_FLAGS so will need to be whitelisted
> before it's usable.
> 
> [ YOCTO #5114 ]
> 
> Signed-off-by: Ross Burton 
> Signed-off-by: Nitin A Kamble 
> ---
>  common/custom-licenses/Intel-Microcode-License | 123
> +
>  .../microcode/intel-microcode_20140624.bb  |  53 +
>  2 files changed, 176 insertions(+)
>  create mode 100644 common/custom-licenses/Intel-Microcode-License
>  create mode 100644 common/recipes-core/microcode/intel-
> microcode_20140624.bb
> 
> diff --git a/common/custom-licenses/Intel-Microcode-License
> b/common/custom-licenses/Intel-Microcode-License
> new file mode 100644
> index 000..af5b41c
> --- /dev/null
> +++ b/common/custom-licenses/Intel-Microcode-License
> @@ -0,0 +1,123 @@
> +INTEL SOFTWARE LICENSE AGREEMENT
> +
> +IMPORTANT - READ BEFORE COPYING, INSTALLING OR USING.
> +Do not use or load this software and any associated materials
> +(collectively, the "Software") until you have carefully read the
> +following terms and conditions. By loading or using the Software, you
> +agree to the terms of this Agreement. If you do not wish to so agree, do not
> install or use the Software.
> +
> +LICENSES: Please Note:
> +- If you are a network administrator, the "Site License" below shall
> +apply to you.
> +- If you are an end user, the "Single User License" shall apply to you.
> +- If you are an original equipment manufacturer (OEM), the "OEM License"
> +shall apply to you.
> +
> +SITE LICENSE. You may copy the Software onto your organization's
> +computers for your organization's use, and you may make a reasonable
> +number of back-up copies of the Software, subject to these conditions:
> +
> +1. This Software is licensed for use only in conjunction with Intel
> +component products. Use of the Software in conjunction with non-Intel
> +component products is not licensed hereunder.
> +2. You may not copy, modify, rent, sell, distribute or transfer any
> +part of the Software except as provided in this Agreement, and you
> +agree to prevent unauthorized copying of the Software.
> +3. You may not reverse engineer, decompile, or disassemble the Software.
> +4. You may not sublicense or permit simultaneous use of the Software by
> +more than one user.
> +5. The Software may include portions offered on terms in addition to
> +those set out here, as set out in a license accompanying those portions.
> +
> +SINGLE USER LICENSE. You may copy the Software onto a single computer
> +for your personal, noncommercial use, and you may make one back-up
> copy
> +of the Software, subject to these conditions:
> +
> +1. This Software is licensed for use only in conjunction with Intel
> +component products. Use of the Software in conjunction with non-Intel
> +component products is not licensed hereunder.
> +2. You may not copy, modify, rent, sell, distribute or transfer any
> +part of the Software except as provided in this Agreement, and you
> +agree to prevent unauthorized copying of the Software.
>

Re: [meta-intel] [Patch v3 0/7] enable microcode loading support for meta-intel BSPs

[Kamble, Nitin A]

> -Original Message-
> From: Hart, Darren
> Sent: Friday, July 18, 2014 3:51 PM
> To: Kamble, Nitin A; Zanussi, Tom; richard.pur...@linuxfoundation.org;
> Burton, Ross
> Cc: meta-intel@yoctoproject.org
> Subject: Re: [Patch v3 0/7] enable microcode loading support for meta-intel
> BSPs
> 
> OK, so after some testing, I realized that this requires all builds of 
> meta-intel
> BSP images to set the license_intel-microcode in the license flags. I don't 
> feel
> there is a need to make this absolutely required. One should be able to get
> the microcode support into the build by adding the license flag, but should
> still be able to build the images as they had previously without it.
> 
> The license flags are there in part to allow people to choose which licenses
> they accept. I don't feel this license should be required to be accepted in
> order to build images for Intel hardware.
> 
> We need to look into how to make this a RECOMMENDS instead of a
> DEPENDS.
> 
That should help, and there is more to it. The initrd recipe also needs to 
accommodate absence of the microcode data file.

Nitin


> Thanks,
> 
> Darren
> 
> On 7/17/14, 15:49, "Kamble, Nitin A"  wrote:
> 
> >From: Nitin A Kamble 
> >
> >This is v3 of the commits incorporating feedback from Ross and Darren.
> >
> >Thanks,
> >Nitin
> >
> >The following changes since commit
> >fef1cbc31ce64d29dedd880274ae6c8a90e0b162:
> >
> >  meta-mohonpeak: Fix README on building mohonpeak BSP layer
> >(2014-07-16
> >10:57:56 -0500)
> >
> >are available in the git repository at:
> >
> >  git://git.yoctoproject.org/meta-intel-contrib nitin/misc
> >
> >http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin/mi
> >sc
> >
> >Nitin A Kamble (7):
> >  meta-intel BSPs: include meta-intel.inc
> >  iucode-tool: a new recipe for loading Intel CPU microcode
> >  intel-microcode: a recipe for Intel microcode datafile
> >  meta-intel BSPs: enable user space microcode loading support
> >  image-ucode.bbclass: a new bbclass for initramfs images
> >  core-image-minimal-initramfs: extend to support early microcode
> >loading
> >  meta-intel.inc: Use microcode enabled initrd for all the Intel BSPs
> >
> > classes/image-ucode.bbclass|  17 +++
> > common/custom-licenses/Intel-Microcode-License | 123
> >+
> > .../images/core-image-minimal-initramfs.bbappend   |   3 +
> > .../microcode/intel-microcode_20140430.bb  |  53 +
> > common/recipes-core/microcode/iucode-tool_1.0.2.bb |  25 +
> > conf/machine/include/meta-intel.inc|  12 ++
> > meta-crownbay/conf/machine/crownbay-noemgd.conf|   1 +
> > meta-emenlow/conf/machine/emenlow-noemgd.conf  |   1 +
> > meta-fri2/conf/machine/fri2-noemgd.conf|   1 +
> > meta-jasperforest/conf/machine/jasperforest.conf   |   1 +
> > meta-nuc/conf/machine/nuc.conf |   1 +
> > meta-sugarbay/conf/machine/sugarbay.conf   |   1 +
> > 12 files changed, 239 insertions(+)
> > create mode 100644 classes/image-ucode.bbclass  create mode 100644
> >common/custom-licenses/Intel-Microcode-License
> > create mode 100644
> >common/recipes-core/images/core-image-minimal-initramfs.bbappend
> > create mode 100644
> >common/recipes-core/microcode/intel-microcode_20140430.bb
> > create mode 100644 common/recipes-core/microcode/iucode-
> tool_1.0.2.bb
> >
> >--
> >1.8.1.4
> >
> >
> 
> 
> --
> Darren Hart   Open Source Technology
> Center
> darren.h...@intel.com Intel Corporation
> 

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

Re: [meta-intel] [Patch v2 6/7] core-image-minimal-initramfs: extend to support early microcode loading

[Kamble, Nitin A]

> -Original Message-
> From: Hart, Darren
> Sent: Friday, July 18, 2014 11:00 AM
> To: Kamble, Nitin A; meta-intel@yoctoproject.org; Zanussi, Tom;
> richard.pur...@linuxfoundation.org; Burton, Ross
> Subject: Re: [Patch v2 6/7] core-image-minimal-initramfs: extend to support
> early microcode loading
> 
> On 7/17/14, 15:27, "Kamble, Nitin A"  wrote:
> 
> >> >+IMAGE_FSTYPES_meta-intel = "cpio.gz.ucode"
> >> >--
> >> >1.8.1.4
> >> >
> >>
> >>
> >> Hrm A meta-intel override... Do we need to introduce a layer
> >>override,  or would the intel-common overrides be sufficient? It would
> >>reduce the  complexity a bit.
> >>
> >I have renamed the override to intel-common now.
> 
> Well, what about the comment below?
> 
> >
> >Nitin
> >
> >> I do see the value in the layer override though as it applies to the
> >>BSPs  that are not yet intel-common - or won't ever be.
I am not clear what is the concern here. 

> 
> If you use the intel common overrides, then machines that don't share a
> common kernel cannot have microcode support? That seems overly
> restrictive to me.


I don't see this restricting it in anyway. 

People who want to use custom kernel will need to ensure they have early
microcode driver enabled in the kernel.

Nitin


> 
> >>
> >> So..
> >>
> >> Acked-by: Darren Hart 
> >>
> >>
> >> --
> >> Darren HartOpen Source Technology
> >> Center
> >> darren.h...@intel.com  Intel
> Corporation
> >>
> >
> >
> 
> 
> --
> Darren Hart   Open Source Technology
> Center
> darren.h...@intel.com Intel Corporation
> 

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

Re: [meta-intel] [PATCH 1/1] image-ucode.bbclass: add dependency on the microcode cpio provider

[Kamble, Nitin A]

> -Original Message-
> From: Hart, Darren
> Sent: Friday, July 18, 2014 10:37 AM
> To: Kamble, Nitin A; Zanussi, Tom; richard.pur...@linuxfoundation.org;
> Burton, Ross
> Cc: meta-intel@yoctoproject.org
> Subject: Re: [PATCH 1/1] image-ucode.bbclass: add dependency on the
> microcode cpio provider
> 
> On 7/18/14, 9:55, "Kamble, Nitin A"  wrote:
> 
> >From: Nitin A Kamble 
> >
> >The ${EARLY_UCODE_CPIO} file is generated by the intel-microcode recipe.
> >Even
> >though the intel-microcode recipe is included for every Intel BSP,
> >mention it here additionally as it won't hurt anything, and it can
> >reveal the dependency to the reviewer easily.
> >
> >Signed-off-by: Nitin A Kamble 
> >---
> > classes/image-ucode.bbclass | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/classes/image-ucode.bbclass b/classes/image-ucode.bbclass
> >index a0a3240..93ac28e 100644
> >--- a/classes/image-ucode.bbclass
> >+++ b/classes/image-ucode.bbclass
> >@@ -11,7 +11,7 @@
> > IMAGE_TYPES += "cpio.gz.ucode"
> > COMPRESSIONTYPES += "gz.ucode"
> > COMPRESS_CMD_gz.ucode = "${COMPRESS_CMD_gz}; cat
> ${EARLY_UCODE_CPIO}
> >${IMAGE_NAME}.rootfs.${type}.gz >
> ${IMAGE_NAME}.rootfs.${type}.gz.ucode"
> >-COMPRESS_DEPENDS_gz.ucode = "${COMPRESS_DEPENDS_gz}"
> >+COMPRESS_DEPENDS_gz.ucode = "${COMPRESS_DEPENDS_gz} intel-
> microcode"
> >
> > # Extentions to image-live.bbclass
> > EARLY_UCODE_CPIO ?= "${DEPLOY_DIR_IMAGE}/microcode.cpio"
> >--
> >1.8.1.4
> >
> >
> 
> 
> OK, but this should just be done as part of 5/7 of the previous series which
> hasn't been merged yet. Can you include it and update your contrib branch?
> No need to resend. I'll then review for any pending comments and pull.
> 
Merged the two commits on the contrib branch.

> One thing I don't think I've seen discussed is the level of testing this has
> received. Maybe I missed it? In any case - what level of testing has this
> received?
As the last commit was only for dependency addition, I did some build testing 
to ensure it does not cause any build breakages.

Thanks,
Nitin


> 
> --
> Darren Hart   Open Source Technology
> Center
> darren.h...@intel.com Intel Corporation
> 

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

Re: [meta-intel] [Patch v2 6/7] core-image-minimal-initramfs: extend to support early microcode loading

[Kamble, Nitin A]

> -Original Message-
> From: Hart, Darren
> Sent: Friday, July 11, 2014 1:55 PM
> To: Kamble, Nitin A; meta-intel@yoctoproject.org; Zanussi, Tom;
> richard.pur...@linuxfoundation.org; Burton, Ross
> Subject: Re: [Patch v2 6/7] core-image-minimal-initramfs: extend to support
> early microcode loading
> 
> On 7/11/14, 11:59, "Kamble, Nitin A"  wrote:
> 
> >From: Nitin A Kamble 
> >
> >Consumes the intel-earlyload-microcode-image to generate an initrd
> >which is extended with the earlyload microcode support.
> >
> >This recipe now generates this additional initrd image:
> >  core-image-minimal-initramfs-${MACHINE}.cpio.gz.ucode
> >
> >Signed-off-by: Nitin A Kamble 
> >---
> > common/recipes-core/images/core-image-minimal-initramfs.bbappend | 3
> >+++
> > 1 file changed, 3 insertions(+)
> > create mode 100644
> >common/recipes-core/images/core-image-minimal-initramfs.bbappend
> >
> >diff --git
> >a/common/recipes-core/images/core-image-minimal-initramfs.bbappend
> >b/common/recipes-core/images/core-image-minimal-initramfs.bbappend
> >new file mode 100644
> >index 000..d836400
> >--- /dev/null
> >+++ b/common/recipes-core/images/core-image-minimal-
> initramfs.bbappend
> >@@ -0,0 +1,3 @@
> >+inherit image-ucode
> >+
> >+IMAGE_FSTYPES_meta-intel = "cpio.gz.ucode"
> >--
> >1.8.1.4
> >
> 
> 
> Hrm A meta-intel override... Do we need to introduce a layer override,
> or would the intel-common overrides be sufficient? It would reduce the
> complexity a bit.
> 
I have renamed the override to intel-common now.

Nitin

> I do see the value in the layer override though as it applies to the BSPs
> that are not yet intel-common - or won't ever be.
> 
> So..
> 
> Acked-by: Darren Hart 
> 
> 
> --
> Darren Hart   Open Source Technology
> Center
> darren.h...@intel.com Intel Corporation
> 

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

Re: [meta-intel] [Patch v2 4/7] meta-intel BSPs: enable user space microcode loading support

[Kamble, Nitin A]

> -Original Message-
> From: Hart, Darren
> Sent: Friday, July 11, 2014 1:53 PM
> To: Kamble, Nitin A; meta-intel@yoctoproject.org; Zanussi, Tom;
> richard.pur...@linuxfoundation.org; Burton, Ross
> Subject: Re: [Patch v2 4/7] meta-intel BSPs: enable user space microcode
> loading support
> 
> On 7/11/14, 11:59, "Kamble, Nitin A"  wrote:
> 
> >From: Nitin A Kamble 
> >
> >Enable user space microcode loading support for all the BSPs using the
> >meta-intel.inc file.
> >
> >Signed-off-by: Nitin A Kamble 
> >---
> > conf/machine/include/meta-intel.inc | 5 +
> > 1 file changed, 5 insertions(+)
> >
> >diff --git a/conf/machine/include/meta-intel.inc
> >b/conf/machine/include/meta-intel.inc
> >index fb9b4a8..4baefc8 100644
> >--- a/conf/machine/include/meta-intel.inc
> >+++ b/conf/machine/include/meta-intel.inc
> >@@ -24,3 +24,8 @@ XSERVER_X86_MATROX_MGA = "xf86-video-mga \
> >
> > XSERVER_X86_ASPEED_AST = "xf86-video-ast \
> >"
> >+
> >+
> >+
> >+# Enable all BSPs from meta-intel layer with user space Intel
> >+microcode
> >loading support.
> >+MACHINE_EXTRA_RRECOMMENDS += "intel-microcode iucode-tool"
> >--
> >1.8.1.4
> >
> >
> 
> Seems like 4 and 7 can be done together. Any particular reason to keep them
> separate?

#4 is for userland microcode loading support

And #7 is for the early boot kernel microcode loading support


Nitin

> 
> 
> --
> Darren Hart   Open Source Technology
> Center
> darren.h...@intel.com Intel Corporation
> 

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

Re: [meta-intel] [PATCHv3 1/2] meta-intel/common: Initial Intel DPDK recipe under recipes-extended

[Kamble, Nitin A]

> -Original Message-
> From: Chan, Wei Sern
> Sent: Wednesday, July 16, 2014 7:50 AM
> To: Kamble, Nitin A; meta-intel@yoctoproject.org
> Cc: Chan, Wei Sern
> Subject: RE: [meta-intel] [PATCHv3 1/2] meta-intel/common: Initial Intel
> DPDK recipe under recipes-extended
> 
> Hi Nitin,
> This is an initial version that I've been working on last 2 weeks and they are
> customers waiting for it right now.
> For DPDK 1.7 recipe is working in progress at the moment.

Thanks for clarification.

Nitin

> 
> Thanks.
> Regards,
> Wei Sern.
> > -Original Message-
> > From: Kamble, Nitin A
> > Sent: Wednesday, July 16, 2014 10:46 PM
> > To: Chan, Wei Sern; meta-intel@yoctoproject.org
> > Subject: RE: [meta-intel] [PATCHv3 1/2] meta-intel/common: Initial
> > Intel DPDK recipe under recipes-extended
> >
> >
> >
> > > -Original Message-
> > > From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
> > > boun...@yoctoproject.org] On Behalf Of wei.sern.c...@intel.com
> > > Sent: Wednesday, July 16, 2014 2:52 AM
> > > To: meta-intel@yoctoproject.org
> > > Subject: [meta-intel] [PATCHv3 1/2] meta-intel/common: Initial Intel
> > > DPDK recipe under recipes-extended
> > >
> > > From: Chan Wei Sern 
> > >
> > > This is an initial version of Intel Data Plane Development Kits
> > > (DPDK) recipe support. This recipe is targetting on Intel DPDK
> > > v1.6.0r2. This recipe is created under meta-intel/common because
> > > Intel DPDK can be commonly used several Intel BSP platforms such as
> > > Romley, Crystal-Forest & Mohon-peak. We resolved examples apps build
> > > failure found in v1.6.0-r2 by cherry-picking patches from
> > > v1.7.0 as they are not planned to be fixed in v1.6.0-r2. The example
> > > app build failure are found in qos_sched, eal_flags_autotest and
> > cmdline_autotest.
> >
> > Hi Wei Sern,
> >   Why not use v1.7.0 then?
> >
> > Nitin
> >
> >
> > >
> > > Signed-off-by: Chan Wei Sern 
> > > ---
> > >  ...ix-build-switches-to-enable-cmdline-tests.patch |  53 +++
> > > ...dpdk- 1.6.0r2-eal-fix-option-base-virtaddr.patch |  35 +
> > > ...k-1.6.0r2-examples- qos_sched-fix-makefile.patch |  35 +
> > >  common/recipes-extended/dpdk/dpdk_1.6.0r2.bb   | 166
> > > +
> > >  4 files changed, 289 insertions(+)
> > >  create mode 100644 common/recipes-extended/dpdk/dpdk/dpdk-
> 1.6.0r2-
> > > app-test-fix-build-switches-to-enable-cmdline-tests.patch
> > >  create mode 100644 common/recipes-extended/dpdk/dpdk/dpdk-
> 1.6.0r2-
> > > eal-fix-option-base-virtaddr.patch
> > >  create mode 100644 common/recipes-extended/dpdk/dpdk/dpdk-
> 1.6.0r2-
> > > examples-qos_sched-fix-makefile.patch
> > >  create mode 100644 common/recipes-extended/dpdk/dpdk_1.6.0r2.bb
> > >
> > > diff --git
> > > a/common/recipes-extended/dpdk/dpdk/dpdk-1.6.0r2-app-test-
> > > fix-build-switches-to-enable-cmdline-tests.patch b/common/recipes-
> > > extended/dpdk/dpdk/dpdk-1.6.0r2-app-test-fix-build-switches-to-enabl
> > > e-
> > > cmdline-tests.patch
> > > new file mode 100644
> > > index 000..87d2ef7
> > > --- /dev/null
> > > +++ b/common/recipes-extended/dpdk/dpdk/dpdk-1.6.0r2-app-test-
> fix-
> > > build-
> > > +++ switches-to-enable-cmdline-tests.patch
> > > @@ -0,0 +1,53 @@
> > > +From cf953d2bfa7df9aa67459b333db4d4d8a9e72fd6 Mon Sep 17
> 00:00:00
> > > 2001
> > > +From: Thomas Monjalon 
> > > +Date: Fri, 27 Jun 2014 11:21:11 +0200
> > > +Subject: [PATCH] app/test: fix build switches to enable cmdline
> > > +tests
> > > +
> > > +Upstream-Status: backport
> > > +Imported patch from: http://dpdk.org/browse/dpdk/log/
> > > +
> > > +There were 2 typos since these commits (in 1.6.0 releases):
> > > + 21a7f4e264 fix build without librte_cmdline
> > > + cac6d08c8b replace --use-device option by --pci-whitelist and
> > > +--vdev In makefiles, the build options are prefixed with
> > > +CONFIG_RTE_ but in .c file, it is only RTE_.
> > > +
> > > +These typos were disabling cmdline unit tests and test of "--vdev
> > eth_ring"
> > > option.
> > > +
> > > +Signed-off-by: Thomas Monjalon 
> > > +Acked-by: Pablo de Lara 
> > > +Signed-off-by: Chan Wei Sern 
> > > +---
> > > +

Re: [meta-intel] [PATCHv3 1/2] meta-intel/common: Initial Intel DPDK recipe under recipes-extended

[Kamble, Nitin A]

> -Original Message-
> From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
> boun...@yoctoproject.org] On Behalf Of wei.sern.c...@intel.com
> Sent: Wednesday, July 16, 2014 2:52 AM
> To: meta-intel@yoctoproject.org
> Subject: [meta-intel] [PATCHv3 1/2] meta-intel/common: Initial Intel DPDK
> recipe under recipes-extended
> 
> From: Chan Wei Sern 
> 
> This is an initial version of Intel Data Plane Development Kits
> (DPDK) recipe support. This recipe is targetting on Intel DPDK v1.6.0r2. This
> recipe is created under meta-intel/common because Intel DPDK can be
> commonly used several Intel BSP platforms such as Romley, Crystal-Forest &
> Mohon-peak. We resolved examples apps build failure found in v1.6.0-r2 by
> cherry-picking patches from
> v1.7.0 as they are not planned to be fixed in v1.6.0-r2. The example app build
> failure are found in qos_sched, eal_flags_autotest and cmdline_autotest.

Hi Wei Sern,
  Why not use v1.7.0 then?

Nitin


> 
> Signed-off-by: Chan Wei Sern 
> ---
>  ...ix-build-switches-to-enable-cmdline-tests.patch |  53 +++  ...dpdk-
> 1.6.0r2-eal-fix-option-base-virtaddr.patch |  35 +  ...k-1.6.0r2-examples-
> qos_sched-fix-makefile.patch |  35 +
>  common/recipes-extended/dpdk/dpdk_1.6.0r2.bb   | 166
> +
>  4 files changed, 289 insertions(+)
>  create mode 100644 common/recipes-extended/dpdk/dpdk/dpdk-1.6.0r2-
> app-test-fix-build-switches-to-enable-cmdline-tests.patch
>  create mode 100644 common/recipes-extended/dpdk/dpdk/dpdk-1.6.0r2-
> eal-fix-option-base-virtaddr.patch
>  create mode 100644 common/recipes-extended/dpdk/dpdk/dpdk-1.6.0r2-
> examples-qos_sched-fix-makefile.patch
>  create mode 100644 common/recipes-extended/dpdk/dpdk_1.6.0r2.bb
> 
> diff --git a/common/recipes-extended/dpdk/dpdk/dpdk-1.6.0r2-app-test-
> fix-build-switches-to-enable-cmdline-tests.patch b/common/recipes-
> extended/dpdk/dpdk/dpdk-1.6.0r2-app-test-fix-build-switches-to-enable-
> cmdline-tests.patch
> new file mode 100644
> index 000..87d2ef7
> --- /dev/null
> +++ b/common/recipes-extended/dpdk/dpdk/dpdk-1.6.0r2-app-test-fix-
> build-
> +++ switches-to-enable-cmdline-tests.patch
> @@ -0,0 +1,53 @@
> +From cf953d2bfa7df9aa67459b333db4d4d8a9e72fd6 Mon Sep 17 00:00:00
> 2001
> +From: Thomas Monjalon 
> +Date: Fri, 27 Jun 2014 11:21:11 +0200
> +Subject: [PATCH] app/test: fix build switches to enable cmdline tests
> +
> +Upstream-Status: backport
> +Imported patch from: http://dpdk.org/browse/dpdk/log/
> +
> +There were 2 typos since these commits (in 1.6.0 releases):
> + 21a7f4e264 fix build without librte_cmdline
> + cac6d08c8b replace --use-device option by --pci-whitelist and --vdev
> +In makefiles, the build options are prefixed with CONFIG_RTE_ but in .c
> +file, it is only RTE_.
> +
> +These typos were disabling cmdline unit tests and test of "--vdev eth_ring"
> option.
> +
> +Signed-off-by: Thomas Monjalon 
> +Acked-by: Pablo de Lara 
> +Signed-off-by: Chan Wei Sern 
> +---
> + app/test/test_cmdline.c   | 2 +-
> + app/test/test_eal_flags.c | 2 +-
> + 2 files changed, 2 insertions(+), 2 deletions(-)
> +
> +diff --git a/app/test/test_cmdline.c b/app/test/test_cmdline.c index
> +77475c4..10a3f77 100644
> +--- a/app/test/test_cmdline.c
>  b/app/test/test_cmdline.c
> +@@ -39,7 +39,7 @@
> + int
> + test_cmdline(void)
> + {
> +-#ifdef CONFIG_RTE_LIBRTE_CMDLINE
> ++#ifdef RTE_LIBRTE_CMDLINE
> + printf("Testind parsing ethernet addresses...\n");
> + if (test_parse_etheraddr_valid() < 0)
> + return -1;
> +diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
> +index a862654..1b80b80 100644
> +--- a/app/test/test_eal_flags.c
>  b/app/test/test_eal_flags.c
> +@@ -317,7 +317,7 @@ test_whitelist_flag(void)
> + const char *wlval3[] = {prgname, prefix, mp_flag, "-n", "1", "-c", "1",
> + pci_whitelist, "09:0B.3,type=test",
> + pci_whitelist, "08:00.1,type=normal", -#ifdef
> +CONFIG_RTE_LIBRTE_PMD_RING
> ++#ifdef RTE_LIBRTE_PMD_RING
> + vdev, "eth_ring,arg=test",
> + #endif
> + };
> +--
> +1.9.1
> +
> diff --git a/common/recipes-extended/dpdk/dpdk/dpdk-1.6.0r2-eal-fix-
> option-base-virtaddr.patch b/common/recipes-extended/dpdk/dpdk/dpdk-
> 1.6.0r2-eal-fix-option-base-virtaddr.patch
> new file mode 100644
> index 000..e724591
> --- /dev/null
> +++ b/common/recipes-extended/dpdk/dpdk/dpdk-1.6.0r2-eal-fix-option-
> base
> +++ -virtaddr.patch
> @@ -0,0 +1,35 @@
> +From be1816f59e772e427fc5815281f9458a9314973a Mon Sep 17 00:00:00
> 2001
> +From: Pablo de Lara 
> +Date: Thu, 19 Jun 2014 16:35:22 +0100
> +Subject: [PATCH] eal: fix option --base-virtaddr
> +
> +Upstream-Status: backport
> +Imported patch from: http://dpdk.org/browse/dpdk/log/
> +
> +When parsing EAL option --base-virtaddr errno was not being set to 0
> +before calling strtoull, therefore function might fail unnecesarily.
> +
> +Signed-off-by: Pablo de Lara 
> +Signed-off-by: A

Re: [meta-intel] [PATCH 1/1] meta-mohonpeak: Fix README on building mohonpeak BSP layer

[Kamble, Nitin A]

> -Original Message-
> From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
> boun...@yoctoproject.org] On Behalf Of wei.sern.c...@intel.com
> Sent: Wednesday, July 16, 2014 3:34 AM
> To: meta-intel@yoctoproject.org
> Subject: [meta-intel] [PATCH 1/1] meta-mohonpeak: Fix README on building
> mohonpeak BSP layer
> 
> From: Chan Wei Sern 
> 
> By following this bblayer prepartion instruction will cause bitbake to fail
> during parsing stage.So to fix this, need to remove the extra line of
> yocto/meta-intel/meta-isg.
> 
> Signed-off-by: Chan Wei Sern 
Acked-By: Nitin A Kamble 


> ---
>  meta-isg/meta-mohonpeak/README | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/meta-isg/meta-mohonpeak/README b/meta-isg/meta-
> mohonpeak/README index 94ceb2b..cd948de 100644
> --- a/meta-isg/meta-mohonpeak/README
> +++ b/meta-isg/meta-mohonpeak/README
> @@ -83,7 +83,6 @@ bblayers.conf, along with the meta-intel layer itself (to
> access  common metadata shared between BSPs) e.g.:
> 
>yocto/meta-intel \
> -  yocto/meta-intel/meta-isg \
>yocto/meta-intel/meta-isg/meta-mohonpeak \
> 
>  To enable the 32-bit Mohon Peak layer, add the mohonpeak-32 MACHINE to
> local.conf:
> --
> 1.9.1
> 
> --
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [Patch v2 5/7] image-ucode.bbclass: a new bbclass for initramfs images

[Kamble, Nitin A]

On 7/14/2014 8:59 AM, Burton, Ross wrote:

On 11 July 2014 19:59,   wrote:

This provides extensions to the image_types and image-live classes to enable
the initramfs recipes with early microcode support.

Can the commit - and a comment in the class - explain what this is
for.  It took me a minute to understand that it's taking whatever the
input is and appending the EARLY_UCODE_CPIO file to it.
This code was sent mainly for review. As I mentioned in the pull request 
header email, this
commit should go in oecore layer. This code becomes very obvious to 
understand once it

goes in the image_types.bbclass file in oecore.

Any recommendation on whether this code should go in 
meta/classes/image_types.bbclass or
a separate meta/classes/image_types_ucode.bbclass file, or keep it like 
this in meta-intel layer?





+COMPRESS_DEPENDS_gz.ucode = "${COMPRESS_DEPENDS_gz}"

Missing dependency on the package that generates the microcode file.
This dependency requirement is satisfied with a line from the 
meta_intel.inc file. That

avoids dependency on the meta-intel layer recipe in the oecore layer.

Nitin


Ross


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

Re: [meta-intel] [PATCH 09/10] core-image-minimal-initramfs: extend to support early microcode loading

[Kamble, Nitin A]

> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Tuesday, June 24, 2014 1:05 PM
> To: Kamble, Nitin A
> Cc: Zanussi, Tom; Hart, Darren; meta-intel@yoctoproject.org
> Subject: Re: [meta-intel] [PATCH 09/10] core-image-minimal-initramfs:
> extend to support early microcode loading
> 
> Hi,
> 
> I've been having a quick look at the image generation code and am
> wondering if appending supplementary cpio blobs to an initramfs is
> something that is actually common and we should add support for that
> directly to the initramfs generation.
I think it is not common. But like there are uboot pieces, we can add x86 ucode 
pieces.

> 
> Alternatively, using IMAGE_POSTPROCESS_COMMAND in core-image-
> minimal-initramfs.bbappend should let you trivially append a cpio (generated
> directly using cpio, not image.bbclass) to the generated image.
> 
This along with RP's do_deploy solution should give the same results as my 
initial ucode image solution. I am trying these out now.

Nitin


> Ross
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 07/10] intel-earlyload-microcode-image.bb: new recipe for ealryload microcode image

[Kamble, Nitin A]

> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Monday, June 23, 2014 9:29 AM
> To: Kamble, Nitin A
> Cc: Zanussi, Tom; Hart, Darren; meta-intel@yoctoproject.org
> Subject: Re: [meta-intel] [PATCH 07/10] intel-earlyload-microcode-image.bb:
> new recipe for ealryload microcode image
> 
> On 20 June 2014 19:52,   wrote:
> > +inherit core-image
> 
> Changing this to just inherit image should remove some of the cruft, but to
> be honest as this is literally just a cpio containing a single file, why not 
> use
> cpio directly?
> 
> Ross

I did thought about it. I wanted to make the microcode blob available like an 
initrd, which if desired can be changed easily without touching the initrd file.

I will see if "inherit image" simplifies the recipe further here.

Thanks,
Nitin
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] VAAPI Issues

[Kamble, Nitin A]

> -Original Message-
> From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
> boun...@yoctoproject.org] On Behalf Of Ong, Boon Leong
> Sent: Wednesday, June 18, 2014 2:49 AM
> To: Stuart Weaver
> Cc: meta-intel@yoctoproject.org; Anuar, Nuhairi
> Subject: Re: [meta-intel] VAAPI Issues
> 
> > You probably want to try upgrading to the latest versions of the vaapi
> > packages, I've a branch at
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-
> > contrib/log/?h=ross/vaapi
> > which is a good start (and intend to finish it off soon).
> >
> > If you still have problems with the latest releases then the
> > maintainer of gstreamer-vaapi is quite responsive to good bug reports.
> >
> 
> Stuart, thanks for your response to me. Please respond to mailing list so that
> everyone follows the discussion here.
> Please try out what Ross is advising.
> If you are still seeing issue, Nuhairi may be able to help follow-up too. 
> Tell us
> how it goes.
> 

Hi Stuart,
  I am not sure what is the issue with Vaapi here. These kind of issues are 
best discussed
on this meta-intel mailing list. If there is bug, which can easily be 
reproduced, then you 
can open a bug at http://bugzilla.yoctoproject.org, which helps in tracking 
progress
of fixing the issue.

Thanks,
Nitin


> --
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 1/1] Provide a time limited kernel extension for the v3.14 kernel

[Kamble, Nitin A]

Sounds very useful here. I will check it out.

Nitin


On 6/12/14, 2:35 AM, "Burton, Ross"  wrote:

>On 12 June 2014 02:35,   wrote:
>>  create mode 100644
>>meta-tlk/recipes-kernel/linux/linux-yocto_3.14.bbappend
>
>You might want to consider using a wildcard bbappend here,
>linux-yocto_%.bbappend.
>
>Ross

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

Re: [meta-intel] [PATCH 1/1] meta-valleyisland: Add linux-yocto 3.10 recipe

[Kamble, Nitin A]

On 5/28/2014 5:40 PM, Ong Boon Leong wrote:

From: Chan Wei Sern 

Added linux-yocto 3.10 due to it cannot be shared with
common intel recipe kernel. The reason cannot be shared as for
valleyisland case has additional feature that is still pending to
pull into LTS/LTSI and hence it cannot be merged into "standard/base".
For this particular reason, a feature branch of "valleyisland-io-1.0"
is introduced to include additional feature. However in order to make
it more align with intel common recipe kernel,machine branch is
pointing to "standard/base" and SRCREV for meta remains closest as
possible.

Signed-off-by: Chan Wei Sern 
Signed-off-by: Chang Rebecca Swee Fun 
Acked-By: Nitin A Kamble 

Acked for dora branch.
Nitin

Signed-off-by: Tom Zanussi 
(cherry picked from commit 756a8fbfcdeca36dcf5a3bea00d26a7762ccf984)
Signed-off-by: Ong Boon Leong 

Conflicts:
  linux-yocto_3.10.bbappend - resolve cherry-pick conflicts by picking
  the recipe to use the latest v3.10.40.
---
  .../recipes-kernel/linux/linux-yocto_3.10.bbappend | 26 +++---
  1 file changed, 18 insertions(+), 8 deletions(-)

diff --git 
a/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappend 
b/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappend
index 8eb014a..084bb47 100644
--- a/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappend
+++ b/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappend
@@ -7,11 +7,15 @@ COMPATIBLE_MACHINE_valleyisland-32 = "valleyisland-32"
  KMACHINE_valleyisland-32 = "valleyisland-32"
  KBRANCH_valleyisland-32 = "standard/base"
  
-KERNEL_FEATURES_append_valleyisland-32 = "features/valleyisland-io/valleyisland-io"

+KERNEL_FEATURES_append_valleyisland-32 = " 
features/valleyisland-io/valleyisland-io \
+  
features/valleyisland-io/valleyisland-io-pci"
  
-LINUX_VERSION_valleyisland-32 = "3.10.35"

-SRCREV_machine_valleyisland-32 = "cee957655fe67826b2e827e2db41f156fa8f0cc4"
-SRCREV_meta_valleyisland-32 = "df3aa753c8826127fb5ad811d56d57168551d6e4"
+LINUX_VERSION_valleyisland-32 = "3.10.40"
+SRCREV_machine_valleyisland-32 = "f53a6114b3a6e8c03ca4752de829887015f4c942"
+SRCREV_meta_valleyisland-32 = "90edb289dccfe838d4e364e1a5815447a6642b98"
+SRCREV_valleyisland-io_valleyisland-32 = 
"8ea4fb625f2654bbdd5dfcb9db67328d21ebe504"
+
+SRC_URI_valleyisland-32 = 
"git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-1.0;name=machine,meta,valleyisland-io"
  
  #

  # MACHINE = valleyisland-64 #
@@ -20,8 +24,14 @@ COMPATIBLE_MACHINE_valleyisland-64 = "valleyisland-64"
  KMACHINE_valleyisland-64 = "valleyisland"
  KBRANCH_valleyisland-64 = "standard/base"
  
-KERNEL_FEATURES_append_valleyisland-64 = "features/valleyisland-io/valleyisland-io"

+KERNEL_FEATURES_append_valleyisland-64 = " 
features/valleyisland-io/valleyisland-io \
+  
features/valleyisland-io/valleyisland-io-pci"
+
+LINUX_VERSION_valleyisland-64 = "3.10.40"
+SRCREV_machine_valleyisland-64 = "f53a6114b3a6e8c03ca4752de829887015f4c942"
+SRCREV_meta_valleyisland-64 = "90edb289dccfe838d4e364e1a5815447a6642b98"
+SRCREV_valleyisland-io_valleyisland-64 = 
"8ea4fb625f2654bbdd5dfcb9db67328d21ebe504"
+
+SRC_URI_valleyisland-64 = 
"git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-1.0;name=machine,meta,valleyisland-io"
  
-LINUX_VERSION_valleyisland-64 = "3.10.35"

-SRCREV_machine_valleyisland-64 = "cee957655fe67826b2e827e2db41f156fa8f0cc4"
-SRCREV_meta_valleyisland-64 = "df3aa753c8826127fb5ad811d56d57168551d6e4"
+module_autoload_i2c-dev = "i2c-dev"


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

Re: [meta-intel] minnowboard: question about the inclusion of linux-firmware

[Kamble, Nitin A]

On 5/28/2014 8:03 AM, Christopher Larson wrote:

Greetings,

I'd thought I'd already sent this, but apparently it had been floating 
around in drafts. I had a quick question about the blanket inclusion 
of linux-firmware. Are there specific firmware images from this needed 
to support the minnowboard hardware, or is it only included for 
potential firmware for e.g. usb wireless adapters?
Many of the wifi drivers, need to load the firmware specific chip to get 
wifi working. AFAIK there is no other hardware which need to pull 
firmware fomr the linux-firmware package.


Nitin


--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics




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

Re: [meta-intel] [PATCH 1/1] meta-valleyisland: Add linux-yocto 3.10 recipe

[Kamble, Nitin A]

On 5/23/2014 10:09 AM, wei.sern.c...@intel.com wrote:

From: Chan Wei Sern 

Added linux-yocto 3.10 due to it cannot be shared with
common intel recipe kernel. The reason cannot be shared as for
valleyisland case has additional feature that is still pending to
pull into LTS/LTSI and hence it cannot be merged into "standard/base".
For this particular reason, a feature branch of "valleyisland-io-1.0"
is introduced to include additional feature. However in order to make
it more align with intel common recipe kernel,machine branch is
pointing to "standard/base" and SRCREV for meta remains closest as
possible.

Signed-off-by: Chan Wei Sern 
Signed-off-by: Chang Rebecca Swee Fun 

Acked-By: Nitin A Kamble 

Hi Tom, Darren,
  Can we pull this in before Penang's Monday?

Thanks,
Nitin


---
  .../recipes-kernel/linux/linux-yocto_3.10.bbappend | 35 ++
  1 file changed, 35 insertions(+)
  create mode 100644 
meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappend

diff --git 
a/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappend 
b/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappend
new file mode 100644
index 000..34e28c1
--- /dev/null
+++ b/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappend
@@ -0,0 +1,35 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+#
+# MACHINE = valleyisland-32 #
+#
+COMPATIBLE_MACHINE_valleyisland-32 = "valleyisland-32"
+KMACHINE_valleyisland-32 = "valleyisland-32"
+KBRANCH_valleyisland-32 = "standard/base"
+KERNEL_FEATURES_valleyisland-32 = " features/valleyisland-io/valleyisland-io \
+   
features/valleyisland-io/valleyisland-io-pci.scc"
+
+LINUX_VERSION_valleyisland-32 = "3.10.40"
+SRCREV_machine_valleyisland-32 = "f53a6114b3a6e8c03ca4752de829887015f4c942"
+SRCREV_meta_valleyisland-32 = "90edb289dccfe838d4e364e1a5815447a6642b98"
+SRCREV_valleyisland-io_valleyisland-32 = 
"8ea4fb625f2654bbdd5dfcb9db67328d21ebe504"
+
+SRC_URI_valleyisland-32 = 
"git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-1.0;name=machine,meta,valleyisland-io"
+
+#
+# MACHINE = valleyisland-64 #
+#
+COMPATIBLE_MACHINE_valleyisland-64 = "valleyisland-64"
+KMACHINE_valleyisland-64 = "valleyisland"
+KBRANCH_valleyisland-64 = "standard/base"
+KERNEL_FEATURES_valleyisland-64 = " features/valleyisland-io/valleyisland-io \
+   
features/valleyisland-io/valleyisland-io-pci.scc"
+
+LINUX_VERSION_valleyisland-64 = "3.10.40"
+SRCREV_machine_valleyisland-64 = "f53a6114b3a6e8c03ca4752de829887015f4c942"
+SRCREV_meta_valleyisland-64 = "90edb289dccfe838d4e364e1a5815447a6642b98"
+SRCREV_valleyisland-io_valleyisland-64 = 
"8ea4fb625f2654bbdd5dfcb9db67328d21ebe504"
+
+SRC_URI_valleyisland-64 = 
"git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},valleyisland-io-1.0;name=machine,meta,valleyisland-io"
+
+module_autoload_i2c-dev = "i2c-dev"


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

Re: [meta-intel] [PATCH 0/4] linux-yocto-dev fixes for master

[Kamble, Nitin A]

On 5/22/2014 9:52 PM, Darren Hart wrote:

Nitin, these could go to daisy, but it's not absolutely critical. Mostly we need
them in master. Preference?

Lets put then in daisy too. It is not going to make much difference 
though, as we are not expecting people to use -dev recipes in the 
release branches.


Thanks,
Nitin


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

Re: [meta-intel] [PATCH 0/5] Clean up corpus recipes

[Kamble, Nitin A]

> -Original Message-
> From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
> boun...@yoctoproject.org] On Behalf Of Burton, Ross
> Sent: Wednesday, May 21, 2014 9:24 AM
> To: meta-intel@yoctoproject.org
> Cc: oon.leong.ong
> Subject: Re: [meta-intel] [PATCH 0/5] Clean up corpus recipes
> 
> As per Nitin's comments, I've just re-pushed this branch
> (ross/canterbury) with extra inline comments.
> 
> Ross
> 
Thanks Ross

Nitin

--
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 1/5] canterbury-corpus: don't skip all QA tests

[Kamble, Nitin A]

Hi BL,
  You also understand why these lines are added. Can you provide comments for 
these lines in the recipes, so that the commits can be pulled in meta-intel?

Thanks,
Nitin


> -Original Message-
> From: Kamble, Nitin A [mailto:nitin.a.kam...@intel.com]
> Sent: Tuesday, May 20, 2014 9:46 AM
> To: Burton, Ross; meta-intel@yoctoproject.org
> Subject: Re: [meta-intel] [PATCH 1/5] canterbury-corpus: don't skip all QA
> tests
> 
> 
> On 5/20/2014 9:17 AM, Ross Burton wrote:
> > Instead of setting ERROR_QA to "" (disabling all tests, instead of
> > just the problematic ones), adding nothing to WARN_QA (cruft from
> > previous revisions), and also marking do_package_qa as noexec (which
> > doesn't work), just set INSANE_SKIP to skip the specific tests that fail 
> > with
> this package.
> >
> > Signed-off-by: Ross Burton 
> > ---
> >   common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb |   10
> ++
> >   1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git
> > a/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
> > b/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
> > index 4dcdea1..d15ad15 100644
> > --- a/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
> > +++ b/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
> > @@ -17,14 +17,6 @@ SRC_URI =
> "http://corpus.canterbury.ac.nz/resources/cantrbry.tar.gz";
> >   SRC_URI[md5sum] = "442e56cfffdf460d25b0b91650a55908"
> >   SRC_URI[sha256sum] =
> "f140e8a5b73d3f53198555a63bfb827889394a42f20825df33c810c3d5e3f8fb"
> >
> > -# Disable architecture QA check for this package since it contains -#
> > pre-compiled executable "sum" for SPARC. The package is used -# for
> > compression benchmarking only.
> > -WARN_QA += ""
> > -ERROR_QA = ""
> > -
> > -do_package_qa[noexec] = "1"
> > -
> >   do_unpack () {
> > mkdir -p ${S}
> > tar -xf ${DL_DIR}/cantrbry.tar.gz -C ${S} @@ -40,3 +32,5 @@
> > do_install () {
> > install -d ${D}${base_libdir}/firmware
> > install -m 644 ${S}/* ${D}${base_libdir}/firmware
> >   }
> > +
> > +INSANE_SKIP_${PN} = "arch ldflags"
> Hi Ross,
>   These are good code cleanups. As there are some special handling in these
> recipes, it demands some explanation in comments why is it done this way.
> That way if someone looks at recipes in future can easily understand why
> these lines are here.
> 
> Thanks,
> Nitin
> 

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

Re: [meta-intel] [PATCH 2/5] canterbury-corpus: rationalise unpack logic

[Kamble, Nitin A]

On 5/20/2014 9:17 AM, Ross Burton wrote:

Instead of manually unpacking, use the subdir parameter to put the tarball into
the right directory.

Signed-off-by: Ross Burton 
---
  .../canterbury-corpus/canterbury-corpus.bb |   16 +++-
  1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb 
b/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
index d15ad15..564dbdb 100644
--- a/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
+++ b/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
@@ -10,25 +10,15 @@ LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425
  
  PR = "r0"
  
-S = "${WORKDIR}/canterbury-corpus"

-
-SRC_URI = "http://corpus.canterbury.ac.nz/resources/cantrbry.tar.gz";
-
+SRC_URI = 
"http://corpus.canterbury.ac.nz/resources/cantrbry.tar.gz;subdir=${BP}";
A comment here why is this done this way, would help for future code 
readers.



  SRC_URI[md5sum] = "442e56cfffdf460d25b0b91650a55908"
  SRC_URI[sha256sum] = 
"f140e8a5b73d3f53198555a63bfb827889394a42f20825df33c810c3d5e3f8fb"
  
-do_unpack () {

-   mkdir -p ${S}
-   tar -xf ${DL_DIR}/cantrbry.tar.gz -C ${S}
-}
-
-do_unpack_append () {
-   rm -rf ${S}/patches
-}
-
  FILES_${PN} = "/lib/firmware/*"
  
  do_install () {

+   rm -rf ${S}/patches
+
Same feedback as the last one here. All the special handling need some 
explaining comments, so that one can easily understand why it is done 
this way without knowing the full context.


Thanks,
Nitin


install -d ${D}${base_libdir}/firmware
install -m 644 ${S}/* ${D}${base_libdir}/firmware
  }


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

Re: [meta-intel] [PATCH 1/5] canterbury-corpus: don't skip all QA tests

[Kamble, Nitin A]

On 5/20/2014 9:17 AM, Ross Burton wrote:

Instead of setting ERROR_QA to "" (disabling all tests, instead of just the
problematic ones), adding nothing to WARN_QA (cruft from previous revisions),
and also marking do_package_qa as noexec (which doesn't work), just set
INSANE_SKIP to skip the specific tests that fail with this package.

Signed-off-by: Ross Burton 
---
  common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb |   10 ++
  1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb 
b/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
index 4dcdea1..d15ad15 100644
--- a/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
+++ b/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
@@ -17,14 +17,6 @@ SRC_URI = 
"http://corpus.canterbury.ac.nz/resources/cantrbry.tar.gz";
  SRC_URI[md5sum] = "442e56cfffdf460d25b0b91650a55908"
  SRC_URI[sha256sum] = 
"f140e8a5b73d3f53198555a63bfb827889394a42f20825df33c810c3d5e3f8fb"
  
-# Disable architecture QA check for this package since it contains

-# pre-compiled executable "sum" for SPARC. The package is used
-# for compression benchmarking only.
-WARN_QA += ""
-ERROR_QA = ""
-
-do_package_qa[noexec] = "1"
-
  do_unpack () {
mkdir -p ${S}
tar -xf ${DL_DIR}/cantrbry.tar.gz -C ${S}
@@ -40,3 +32,5 @@ do_install () {
install -d ${D}${base_libdir}/firmware
install -m 644 ${S}/* ${D}${base_libdir}/firmware
  }
+
+INSANE_SKIP_${PN} = "arch ldflags"

Hi Ross,
 These are good code cleanups. As there are some special handling in 
these recipes, it demands some explanation in comments why is it done 
this way. That way if someone looks at recipes in future can easily 
understand why these lines are here.


Thanks,
Nitin


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

Re: [meta-intel] NUC + efi

[Kamble, Nitin A]

> -Original Message-
> From: Stoicescu, CorneliuX
> Sent: Monday, May 19, 2014 1:20 AM
> To: Kamble, Nitin A; meta-intel@yoctoproject.org
> Subject: RE: [meta-intel] NUC + efi
> 
> > -Original Message-
> > From: Kamble, Nitin A
> > Sent: Friday, May 16, 2014 7:18 PM
> > To: Stoicescu, CorneliuX; meta-intel@yoctoproject.org
> > Subject: Re: [meta-intel] NUC + efi
> >
> >
> > On 5/16/2014 7:50 AM, Stoicescu, CorneliuX wrote:
> > > Hello,
> > >
> > > In order to make the NUC BSP compatible with the hardware automation
> > features in Yocto 1.6, we need it to have EFI support. As such, would
> > it be agreeable to have the following patch added to the meta-intel layer?
> > It is ok, if it does not break the BPS.
> >
> > Nitin
> >
> 
> What would be the required tests to see if it does or does not break the BSP?
> Would a live boot + install be enough?


Yes, for this particular change, that should be enough.

Nitin

> 
> Regards,
> Corneliu
> 
> > > diff --git a/meta-nuc/conf/machine/nuc.conf b/meta-
> > nuc/conf/machine/nuc.conf index fdbbbda..2b1b9a3 100644
> > > --- a/meta-nuc/conf/machine/nuc.conf
> > > +++ b/meta-nuc/conf/machine/nuc.conf
> > > @@ -7,7 +7,7 @@
> > >   # i.e. Ivy Bridge + Panther Point
> > >
> > >   PREFERRED_VERSION_linux-yocto ?= "3.14%"
> > > -MACHINE_FEATURES += "va-impl-intel wifi"
> > > +MACHINE_FEATURES += "va-impl-intel wifi efi"
> > >
> > >   require conf/machine/include/intel-corei7-64-common.inc
> > >   require conf/machine/include/intel-common-pkgarch.inc
> > >
> > > Regards,
> > > Corneliu
> > > Yocto QA

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

Re: [meta-intel] NUC + efi

[Kamble, Nitin A]

On 5/16/2014 7:50 AM, Stoicescu, CorneliuX wrote:

Hello,

In order to make the NUC BSP compatible with the hardware automation features 
in Yocto 1.6, we need it to have EFI support. As such, would it be agreeable to 
have the following patch added to the meta-intel layer?

It is ok, if it does not break the BPS.

Nitin


diff --git a/meta-nuc/conf/machine/nuc.conf b/meta-nuc/conf/machine/nuc.conf 
index fdbbbda..2b1b9a3 100644
--- a/meta-nuc/conf/machine/nuc.conf
+++ b/meta-nuc/conf/machine/nuc.conf
@@ -7,7 +7,7 @@
  # i.e. Ivy Bridge + Panther Point

  PREFERRED_VERSION_linux-yocto ?= "3.14%"
-MACHINE_FEATURES += "va-impl-intel wifi"
+MACHINE_FEATURES += "va-impl-intel wifi efi"

  require conf/machine/include/intel-corei7-64-common.inc
  require conf/machine/include/intel-common-pkgarch.inc

Regards,
Corneliu
Yocto QA


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

Re: [meta-intel] [PATCH 0/3] meta-intel: few fixes for the master & daisy branches

[Kamble, Nitin A]

On 5/14/2014 1:12 PM, nitin.a.kam...@intel.com wrote:

From: Nitin A Kamble 

These commits do the following:
1: convert crownbay-noemgd & fri2-emgd BSPs to use the common v3.14 kernel

Hi Tom,
  The v3.14 common kernel is working fine with crownbay-noemgd and 
fri2-noemgd BSPs.

Nitin


2: fix the v3.10 RT kernel build, by updating the kernel machine branch SRCREV

Thanks,
Nitin

The following changes since commit 7ae3f57eae1401a7517b2c3b48d5dbb5c6471972:

   fri2: Update kernel branch SRCREVs for linux-yocto_3.14 (2014-05-14 09:28:25 
-0500)

are available in the git repository at:

   git://git.yoctoproject.org/meta-intel-contrib nitin/misc
   http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin/misc

Nitin A Kamble (3):
   crownbay-noemgd: use the common v3.14 kernel
   fri2-noemgd: use the common v3.14 kernel
   common: update SRCREVs for linux-yocto-rt_3.10

  common/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend |  4 ++--
  meta-crownbay/conf/machine/crownbay-noemgd.conf  |  1 +
  meta-crownbay/recipes-kernel/linux/linux-yocto_3.14.bbappend | 10 --
  meta-fri2/conf/machine/fri2-noemgd.conf  |  1 +
  meta-fri2/recipes-kernel/linux/linux-yocto_3.14.bbappend | 11 ---
  5 files changed, 4 insertions(+), 23 deletions(-)
  delete mode 100644 
meta-crownbay/recipes-kernel/linux/linux-yocto_3.14.bbappend
  delete mode 100644 meta-fri2/recipes-kernel/linux/linux-yocto_3.14.bbappend



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

Re: [meta-intel] [PATCH 0/3] meta-intel: SRCREV updates for -noemgd BSPs

[Kamble, Nitin A]

On 5/14/2014 7:29 AM, Tom Zanussi wrote:

On Tue, 2014-05-13 at 17:38 -0700, nitin.a.kam...@intel.com wrote:

From: Nitin A Kamble 

These bring the latest commits from the linux-yocto 3.14 kernel repository.
These are also been validated on emenlow-noemgd BSP.


Pulled into daisy/master.

One request for the future - please use the standard form 'BSP: subject'
instead of 'BSP: recipe: subject' e.g. instead of

   crownbay: linux-yocto_3.14: update kernel branch SRCREVs

something like:

   crownbay: Update kernel branch SRCREVs for linux-yocto_3.14
Thanks for the suggestion. It is a bit of challenge to fit a meaningful 
header in few characters. and I was using that scheme to save few 
characters. I will try the other approach now.

Nitin



Thanks,

Tom


Thanks,
Nitin

The following changes since commit 358a1807b01a56d1da05cfad00d33ea45187b25a:

   fri2-noemgd: Use standard/base machine branch for linux-yocto_3.14 
(2014-05-13 16:12:58 -0500)

are available in the git repository at:

   git://git.yoctoproject.org/meta-intel-contrib nitin/misc
   http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin/misc

Nitin A Kamble (3):
   crownbay: linux-yocto_3.14: update kernel branch SRCREVs
   emenlow: linux-yocto_3.14: update kernel branch SRCREVs
   fri2: linux-yocto_3.14: update kernel branch SRCREVs

  meta-crownbay/recipes-kernel/linux/linux-yocto_3.14.bbappend | 4 ++--
  meta-emenlow/recipes-kernel/linux/linux-yocto_3.14.bbappend  | 4 ++--
  meta-fri2/recipes-kernel/linux/linux-yocto_3.14.bbappend | 4 ++--
  3 files changed, 6 insertions(+), 6 deletions(-)





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

Re: [meta-intel] [PATCH] linux-yocto: Update intel-common 3.14 SRCREVs for Baytrail support

[Kamble, Nitin A]

On 5/13/2014 4:04 PM, Darren Hart wrote:

Update the standard/base branch and the meta branch to include the
latest Baytrail support available in the standard/base branch. Includes
fixes for PCI enumeration, SD in ACPI mode, new GPIO HID, and various
other fixes.

Signed-off-by: Darren Hart 

Acked-By: Nitin A Kamble 

This is working fine with emenlow and NUC BSPs here.
Nitin


---
  .../recipes-kernel/linux/linux-yocto_3.14.bbappend |8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/common/recipes-kernel/linux/linux-yocto_3.14.bbappend 
b/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
index 55002f1..2a3ed90 100644
--- a/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto_3.14.bbappend
@@ -5,16 +5,16 @@ KERNEL_FEATURES_INTEL_COMMON += "features/amt/mei/mei.scc"
  
  LINUX_VERSION_core2-32-intel-common = "3.14.2"

  COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
-SRCREV_meta_core2-32-intel-common = "71d5b64a173f51107bf947ceef80a5a7c8d72a7d"
-SRCREV_machine_core2-32-intel-common = 
"b0b9c962ea01f9356fc1542b9696ebe4a38e196a"
+SRCREV_meta_core2-32-intel-common = "11e091dc40c53af6ea08ce491ae50fbb1b0b6377"
+SRCREV_machine_core2-32-intel-common = 
"d0047ab24e8e92fc2a116b0bccfa10d6b84985be"
  KMACHINE_core2-32-intel-common = "intel-core2-32"
  KBRANCH_core2-32-intel-common = "standard/base"
  KERNEL_FEATURES_append_core2-32-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON}"
  
  LINUX_VERSION_corei7-64-intel-common = "3.14.2"

  COMPATIBLE_MACHINE_corei7-64-intel-common = "${MACHINE}"
-SRCREV_meta_corei7-64-intel-common = "71d5b64a173f51107bf947ceef80a5a7c8d72a7d"
-SRCREV_machine_corei7-64-intel-common = 
"b0b9c962ea01f9356fc1542b9696ebe4a38e196a"
+SRCREV_meta_corei7-64-intel-common = "11e091dc40c53af6ea08ce491ae50fbb1b0b6377"
+SRCREV_machine_corei7-64-intel-common = 
"d0047ab24e8e92fc2a116b0bccfa10d6b84985be"
  KMACHINE_corei7-64-intel-common = "intel-corei7-64"
  KBRANCH_corei7-64-intel-common = "standard/base"
  KERNEL_FEATURES_append_corei7-64-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON}"


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

Re: [meta-intel] [PATCH 0/2] Update Calgary Corpus and Canterbury Corpus recipe

[Kamble, Nitin A]

On 5/12/2014 12:16 PM, wei.sern.c...@intel.com wrote:

From: Chan Wei Sern 

Hi All,

This is a patch series to fix do_install() issues from
calgary corpus recipe and canterbury corpus recipe.

To fix that, we used suggestion from Nitin that to add
do_unpack_append() to remove "patches" folder which will cause build issue.
This approach is applied to both of the recipe.

Please help to pull this patch into meta-intel:daisy branch and 
meta-intel:master branch.
These changes are well contained, so I am not worried these commits 
affecting other BSPs.


Acked-By: Nitin A Kamble 


Nitin



Thanks.
Regards,
Chan Wei Sern
The following changes since commit e31788c193b5ff9a157b456b201e7572280c8ef6:

   fri2: linux-yocto_3.14 update meta SRCREV (2014-05-09 11:17:23 -0500)

are available in the git repository at:

   git://git.yoctoproject.org/meta-intel-contrib wchan9/intel-common-daisy
   
http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=wchan9/intel-common-daisy

Chan Wei Sern (2):
   meta-intel/common: Added do_unpack_append() to Calgary Corpus recipe
   meta-intel/common: Added do_unpack_append() to Canterbury Corpus
 recipe

  common/recipes-corpus/calgary-corpus/calgary-corpus.bb   |5 +
  common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb |4 
  2 files changed, 9 insertions(+)



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

Re: [meta-intel] [PATCHv2 00/11] meta-isg: update all ISGs platform to align YP1.6

[Kamble, Nitin A]

On 5/9/2014 3:03 PM, wei.sern.c...@intel.com wrote:

From: Chan Wei Sern 

Hi All,

This is a patch series to align with Yocto 1.6 BSP refresh.

Overall, this patchset consists following of:
1. Added meta-valleyisland,meta-mohonpeak under meta-isg.
2. Enable ASPEED Tech Graphic Card.

For this patchset I have done below:
1. Build sucessfully with machine specific for all ISGs platform as list below
-crystalforest-gladden and crystalforest-server
-romley and romley-ivb
-valleyisland-32 and valleyisland-64
-mohonpeak32 and mohonpeak64
-haswell-wc
2. Boot smoothly on each of the platforms and confirmed all drivers are loaded 
properly
via lspci and dmesg.

What have been since last submission:
1. Removed the patch set that has recipe-kernel for each meta-isg platforms.

(meta-crystalforest,meta-romley,meta-haswell-wc,meta-valleyisland,meta-mohonpeak)
2. Re-include intel-common-pkgarch.inc for all meta-isg platforms.
3. Update haswell-wc.conf to have included meta-intel.inc,APPEND and also
PREFFERED_PROVIDER.
3. Update common/recipes-kernel to include valleyisland-io features.
4. Removed patch series that is trying to fix do_install and do_append on
calgary-corpus.bb and calgary-corpus.bb. We will revisit this item on next 
submission.


Please help to pull this patch into meta-intel:daisy branch.

Acked-By: Nitin A Kamble 
All the commits look reasonable to pull in.

Thanks for the quick work BL, Chan Wei & Rebecca,

Nitin

Thanks.
Regards,
Chan Wei Sern
The following changes since commit 89dffe15a9860ebec535b4c3fac525c93774a66b:

   fri2 linux-yocto_3.10: update meta branch SRCREV (2014-05-07 11:57:32 -0500)

are available in the git repository at:

   git://git.yoctoproject.org/meta-intel-contrib wchan9/intel-common-daisy
   
http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=wchan9/intel-common-daisy

Chan Wei Sern (5):
   meta-mohonpeak: new BSP layer for Intel Atom Processor C2000
   meta-mohonpeak: provide machine configuration for mohonpeak
   meta-valleyisland: provide machine configuration for valleyisland
   meta-valleyisland: provide a formfactor for the valleyisland BSP
   meta-haswell-wc: provide meta-intel.inc in machine configuration

Ong Boon Leong (4):
   xf86-video-ast: new recipe for ASPEED Technology Card
   meta-intel.inc: Enable ASPEED Tech Graphic Card
   meta-mohonpeak: provide a formfactor for the mohonpeak BSP
   meta-intel/common: Suppress canterbury corpus QA arch-check

Rebecca Chang Swee Fun (2):
   meta-valleyisland: new BSP layer for Intel Atom E38XX Processor
   meta-intel/common: add valleyisland-io feature support in kernel
 recipes

  .../canterbury-corpus/canterbury-corpus.bb |5 +-
  .../xorg-driver/xf86-video-ast_0.98.0.bb   |   12 ++
  .../linux/linux-yocto-rt_3.10.bbappend |3 +-
  .../recipes-kernel/linux/linux-yocto_3.10.bbappend |5 +-
  conf/machine/include/meta-intel.inc|2 +
  .../meta-haswell-wc/conf/machine/haswell-wc.conf   |9 +-
  meta-isg/meta-mohonpeak/COPYING.MIT|   17 ++
  meta-isg/meta-mohonpeak/README |  146 +
  meta-isg/meta-mohonpeak/README.sources |   18 ++
  meta-isg/meta-mohonpeak/conf/layer.conf|   12 ++
  .../meta-mohonpeak/conf/machine/mohonpeak32.conf   |   22 ++
  .../meta-mohonpeak/conf/machine/mohonpeak64.conf   |   22 ++
  .../formfactor/formfactor/mohonpeak32/machconfig   |3 +
  .../formfactor/formfactor/mohonpeak64/machconfig   |3 +
  .../recipes-bsp/formfactor/formfactor_0.0.bbappend |1 +
  meta-isg/meta-valleyisland/COPYING.MIT |   17 ++
  meta-isg/meta-valleyisland/README  |  218 
  meta-isg/meta-valleyisland/README.sources  |   18 ++
  meta-isg/meta-valleyisland/conf/layer.conf |   14 ++
  .../conf/machine/valleyisland-32.conf  |   23 +++
  .../conf/machine/valleyisland-64.conf  |   25 +++
  .../formfactor/valleyisland-32/machconfig  |3 +
  .../formfactor/valleyisland-64/machconfig  |3 +
  .../recipes-bsp/formfactor/formfactor_0.0.bbappend |1 +
  24 files changed, 597 insertions(+), 5 deletions(-)
  create mode 100644 
common/recipes-graphics/xorg-driver/xf86-video-ast_0.98.0.bb
  create mode 100644 meta-isg/meta-mohonpeak/COPYING.MIT
  create mode 100644 meta-isg/meta-mohonpeak/README
  create mode 100644 meta-isg/meta-mohonpeak/README.sources
  create mode 100644 meta-isg/meta-mohonpeak/conf/layer.conf
  create mode 100644 meta-isg/meta-mohonpeak/conf/machine/mohonpeak32.conf
  create mode 100644 meta-isg/meta-mohonpeak/conf/machine/mohonpeak64.conf
  create mode 100644 
meta-isg/meta-mohonpeak/recipes-bsp/formfactor/formfactor/mohonpeak32/machconfig
  create mode 100644 
meta-isg/meta-mohonpeak/recipes-bsp/formfactor/formfactor/mohonpeak64/machconfig
  create mode 100644 
meta-isg/meta-mohonpeak/recipes-bsp/formfactor/formf

Re: [meta-intel] [PATCH 11/21] meta-intel/common: Suppress canterbury corpus QA arch-check

[Kamble, Nitin A]

On 5/8/2014 2:38 PM, Ong, Boon Leong wrote:

'sum' is a SPARC executable bundled in canterbury corpus tarball.
By installing this file on x86 file-system, it results in QA
architecture-check warning. As the package is only meant for
compression benchmarking purpose, we would suppress the QA warning
check for architecture compatibility.

Can the 'sum' file be removed from install step instead?

I will not suggest so because it is part of the standard corpus used for 
compression
performance bench-marking. Without this file, the benchmark will not be 
complete.

I see, then there is no way other than muting the QA warning.
Nitin

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

Re: [meta-intel] [PATCH 00/21] meta-isg: update all ISGs platform to align YP1.6

[Kamble, Nitin A]

On 5/7/2014 5:19 PM, wei.sern.c...@intel.com wrote:

From: Chan Wei Sern 

Hi All,

This is a patch series to align with Yocto 1.6 BSP refresh.

Overall, this patchset consists following of:
1. Introduce conf/layer.conf and also common/recipe-kernel under meta-isg.
This is to facilitate Intel common build for all ISG related platforms.
2. Added meta-valleyisland,meta-mohonpeak under meta-isg.
3. Added recipe-kernel for all ISG related platform under meta-isg folder and 
this also
includes meta-romley and also meta-crystalforest. This allows ISG
related platforms to have control over preferred linux-yocto version and 
branch.
4. Removed the used of intel-common-pkgarch.inc from meta-crystalforest and 
meta-romley.
Since we like to have control over preferred linux-yocto version for 
machine specific
build and for this reason intel-common-pkgarch.inc is not needed.
5. Enable ASPEED Tech Graphic Card.

For this patchset I have done below:
1. Build sucessfully with machine specific for all ISGs platform as list below
-crystalforest-gladden and crystalforest-server
-romley and romley-ivb
-valleyisland-32 and valleyisland-64
-mohonpeak32 and mohonpeak64
-haswell-wc
2. Boot smoothly on each of the platforms and confirmed all drivers are loaded 
properly
via lspci and dmesg.

Please help to pull this patch into meta-intel daisy branch.
I replied to few commits. One concern is that you are using separate 
kernel for each BSP here. In meta-intel

we are trying to consolidate the kernel for all BSPs into smaller set.
  I have CCed Darren on these emails, as I will like to see his Ack for 
these commits.


Thanks,
Nitin



Thanks.
Regards,
Chan Wei Sern
The following changes since commit d8e9e84375949ea82dadf214a04e94a2f871f5ce:

   fri2/linux-yocto_3.10: update SRCREVS to 3.10.38-ltsi (2014-05-05 12:42:35 
-0500)

are available in the git repository at:

   git://git.yoctoproject.org/meta-intel-contrib wchan9/intel-common-daisy
   
http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=wchan9/intel-common-daisy

Chan Wei Sern (14):
   meta-isg: linux-yocto_3.10 common SRCREV for all ISG BSPs
   meta-isg: linux-yocto-rt_3.10 common SRCREV for all ISG BSPs
   meta-mohonpeak: new BSP layer for Intel Atom Processor C2000
   meta-mohonpeak: provide machine configuration for mohonpeak
   meta-valleyisland: new BSP layer for Intel Atom E38XX Processor
   meta-valleyisland: provide machine configuration for valleyisland
   meta-valleyisland: provide a formfactor for the valleyisland BSP
   meta-crystalforest: removed using of intel-common-pkgarch.inc
   meta-romley: remove using of intel-common-pkgarch.inc
   meta-crystalforest: Add linux-yocto_3.10 support
   meta-romley: Add linux-yocto_3.10 support
   meta-haswell-wc: Add linux-yocto_3.10 support
   meta-mohonpeak: Add linux-yocto_3.10 support
   meta-valleyisland: Add linux-yocto_3.10 and linux-yocto-rt_3.10

Ong Boon Leong (7):
   meta-isg: add layer.conf
   xf86-video-ast: new recipe for ASPEED Technology Card
   meta-intel.inc: Enable ASPEED Tech Graphic Card
   meta-mohonpeak: provide a formfactor for the mohonpeak BSP
   meta-intel/common: Update Calgary Corpus do_install recipe
   meta-intel/common: Update Canterbury Corpus do_install recipe
   meta-intel/common: Suppress canterbury corpus QA arch-check

  .../calgary-corpus/calgary-corpus.bb   |   27 ++-
  .../canterbury-corpus/canterbury-corpus.bb |   25 ++-
  .../xorg-driver/xf86-video-ast_0.98.0.bb   |   12 ++
  conf/machine/include/meta-intel.inc|2 +
  .../conf/machine/crystalforest-gladden.conf|1 -
  .../conf/machine/crystalforest-server.conf |1 -
  .../recipes-kernel/linux/linux-yocto_3.10.bbappend |   25 +++
  .../linux/linux-yocto-rt_3.10.bbappend |   12 ++
  .../recipes-kernel/linux/linux-yocto_3.10.bbappend |   12 ++
  meta-isg/conf/layer.conf   |   10 +
  .../recipes-kernel/linux/linux-yocto_3.10.bbappend |9 +
  meta-isg/meta-mohonpeak/COPYING.MIT|   17 ++
  meta-isg/meta-mohonpeak/README |  146 +
  meta-isg/meta-mohonpeak/README.sources |   18 ++
  meta-isg/meta-mohonpeak/conf/layer.conf|   12 ++
  .../meta-mohonpeak/conf/machine/mohonpeak32.conf   |   21 ++
  .../meta-mohonpeak/conf/machine/mohonpeak64.conf   |   21 ++
  .../formfactor/formfactor/mohonpeak32/machconfig   |3 +
  .../formfactor/formfactor/mohonpeak64/machconfig   |3 +
  .../recipes-bsp/formfactor/formfactor_0.0.bbappend |1 +
  .../recipes-kernel/linux/linux-yocto_3.10.bbappend |   23 +++
  meta-isg/meta-valleyisland/COPYING.MIT |   17 ++
  meta-isg/meta-valleyisland/README  |  218 
  meta-isg/meta-valleyisland/README.sources  |   18 ++
  meta-isg/meta-valleyisland/conf/layer.conf |   14 ++
  .../conf/machine/valleyisland-32.conf

Re: [meta-intel] [PATCH 21/21] meta-valleyisland: Add linux-yocto_3.10 and linux-yocto-rt_3.10

[Kamble, Nitin A]

Why not using the common kernel here?

Nitin

On 5/7/2014 5:19 PM, wei.sern.c...@intel.com wrote:

From: Chan Wei Sern 

Add linux-yocto_3.10 and also linux-yocto-rt_3.10 on Intel
BayTrail based platform. KBRANCH in linux-yocto_3.10 is pointing
to "standard/base" and KBRANCH in linux-yocto-rt_3.10 is pointing
to "standard/preempt-rt/base". SRCREV_machine and SRCREV_meta
point to 3.10.38 for both of the bbappend. Update LINUX_VERSION
in both of the bbappend to reflect the 3.10.38 changes.

Signed-off-by: Chan Wei Sern 
Signed-off-by: Chang Rebecca Swee Fun 
---
  .../linux/linux-yocto-rt_3.10.bbappend |   27 
  .../recipes-kernel/linux/linux-yocto_3.10.bbappend |   27 
  2 files changed, 54 insertions(+)
  create mode 100644 
meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
  create mode 100644 
meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappend

diff --git 
a/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend 
b/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
new file mode 100644
index 000..e6826bf
--- /dev/null
+++ 
b/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
@@ -0,0 +1,27 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+#
+# MACHINE = valleyisland-32 #
+#
+COMPATIBLE_MACHINE_valleyisland-32 = "valleyisland-32"
+KMACHINE_valleyisland-32 = "valleyisland-32"
+KBRANCH_valleyisland-32 = "standard/preempt-rt/base"
+
+KERNEL_FEATURES_append_valleyisland-32 = 
"features/valleyisland-io/valleyisland-io"
+
+LINUX_VERSION_valleyisland-32 = "3.10.38"
+SRCREV_machine_valleyisland-32 = "8aa9023c5e2e2ca4180e971da9a2c139d5b3c79e"
+SRCREV_meta_valleyisland-32 = "617c6158c3d5b931f0d6131e0b0a7b374c792599"
+
+#
+# MACHINE = valleyisland-64 #
+#
+COMPATIBLE_MACHINE_valleyisland-64 = "valleyisland-64"
+KMACHINE_valleyisland-64 = "valleyisland"
+KBRANCH_valleyisland-64 = "standard/preempt-rt/base"
+
+KERNEL_FEATURES_append_valleyisland-64 = 
"features/valleyisland-io/valleyisland-io"
+
+LINUX_VERSION_valleyisland-64 = "3.10.38"
+SRCREV_machine_valleyisland-64 = "8aa9023c5e2e2ca4180e971da9a2c139d5b3c79e"
+SRCREV_meta_valleyisland-64 ="617c6158c3d5b931f0d6131e0b0a7b374c792599"
diff --git 
a/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappend 
b/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappend
new file mode 100644
index 000..e54c367
--- /dev/null
+++ b/meta-isg/meta-valleyisland/recipes-kernel/linux/linux-yocto_3.10.bbappend
@@ -0,0 +1,27 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+#
+# MACHINE = valleyisland-32 #
+#
+COMPATIBLE_MACHINE_valleyisland-32 = "valleyisland-32"
+KMACHINE_valleyisland-32 = "valleyisland-32"
+KBRANCH_valleyisland-32 = "standard/base"
+
+KERNEL_FEATURES_append_valleyisland-32 = " 
features/valleyisland-io/valleyisland-io"
+
+LINUX_VERSION_valleyisland-32 = "3.10.38"
+SRCREV_machine_valleyisland-32 = "02f7e63e56c061617957388c23bd5cf9b05c5388"
+SRCREV_meta_valleyisland-32 = "617c6158c3d5b931f0d6131e0b0a7b374c792599"
+
+#
+# MACHINE = valleyisland-64 #
+#
+COMPATIBLE_MACHINE_valleyisland-64 = "valleyisland-64"
+KMACHINE_valleyisland-64 = "valleyisland"
+KBRANCH_valleyisland-64 = "standard/base"
+
+KERNEL_FEATURES_append_valleyisland-64 = " 
features/valleyisland-io/valleyisland-io"
+
+LINUX_VERSION_valleyisland-64 = "3.10.38"
+SRCREV_machine_valleyisland-64 = "02f7e63e56c061617957388c23bd5cf9b05c5388"
+SRCREV_meta_valleyisland-64 = "617c6158c3d5b931f0d6131e0b0a7b374c792599"


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

Re: [meta-intel] [PATCH 20/21] meta-mohonpeak: Add linux-yocto_3.10 support

[Kamble, Nitin A]

Again, why not use the common kernel here?

Nitin

On 5/7/2014 5:19 PM, wei.sern.c...@intel.com wrote:

From: Chan Wei Sern 

Add linux-yocto_3.10 support on Intel Mohonpeak
platform. KBRANCH is pointing to "standard/base" with
SRCREV_machine points to 3.10.38.Update LINUX_VERSION
to reflect the 3.10.38 changes.

For SRCREV_meta,I will have to point to this particular
older commit:
  5824403b   intel-common: Add preempt-rt ktype targets

The reason is issue is found on latest commit or commit
after that. We are still working on to solve this issue.

Signed-off-by: Chan Wei Sern 
---
  .../recipes-kernel/linux/linux-yocto_3.10.bbappend |   23 
  1 file changed, 23 insertions(+)
  create mode 100644 
meta-isg/meta-mohonpeak/recipes-kernel/linux/linux-yocto_3.10.bbappend

diff --git 
a/meta-isg/meta-mohonpeak/recipes-kernel/linux/linux-yocto_3.10.bbappend 
b/meta-isg/meta-mohonpeak/recipes-kernel/linux/linux-yocto_3.10.bbappend
new file mode 100644
index 000..acf2fc2
--- /dev/null
+++ b/meta-isg/meta-mohonpeak/recipes-kernel/linux/linux-yocto_3.10.bbappend
@@ -0,0 +1,23 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+#
+# MACHINE = mohonpeak32 #
+#
+COMPATIBLE_MACHINE_mohonpeak32 = "mohonpeak32"
+KMACHINE_mohonpeak32  = "mohonpeak32"
+KBRANCH_mohonpeak32  = "standard/base"
+
+LINUX_VERSION_mohonpeak32 = "3.10.38"
+SRCREV_machine_mohonpeak32 =  "02f7e63e56c061617957388c23bd5cf9b05c5388"
+SRCREV_meta_mohonpeak32 = "5824403ba2b877eca33969425ac1ac5dbeb72720"
+
+#
+# MACHINE = mohonpeak64 #
+#
+COMPATIBLE_MACHINE_mohonpeak64 = "mohonpeak64"
+KMACHINE_mohonpeak64  = "mohonpeak"
+KBRANCH_mohonpeak64  = "standard/base"
+
+LINUX_VERSION_mohonpeak64 = "3.10.38"
+SRCREV_machine_mohonpeak64 =  "02f7e63e56c061617957388c23bd5cf9b05c5388"
+SRCREV_meta_mohonpeak64 = "5824403ba2b877eca33969425ac1ac5dbeb72720"


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

Re: [meta-intel] [PATCH 19/21] meta-haswell-wc: Add linux-yocto_3.10 support

[Kamble, Nitin A]

Same comment as the last one.

Nitin

On 5/7/2014 5:19 PM, wei.sern.c...@intel.com wrote:

From: Chan Wei Sern 

Add linux-yocto_3.10 support on Intel Haswell
Walnut Canyon platform. KBRANCH is pointing to
"standard/base" with SRCREV_machine and SRCREV_meta
point to 3.10.38. Update LINUX_VERSION to reflect
the 3.10.38 changes.

Signed-off-by: Chan Wei Sern 
---
  .../recipes-kernel/linux/linux-yocto_3.10.bbappend|9 +
  1 file changed, 9 insertions(+)
  create mode 100644 
meta-isg/meta-haswell-wc/recipes-kernel/linux/linux-yocto_3.10.bbappend

diff --git 
a/meta-isg/meta-haswell-wc/recipes-kernel/linux/linux-yocto_3.10.bbappend 
b/meta-isg/meta-haswell-wc/recipes-kernel/linux/linux-yocto_3.10.bbappend
new file mode 100644
index 000..0c7deef
--- /dev/null
+++ b/meta-isg/meta-haswell-wc/recipes-kernel/linux/linux-yocto_3.10.bbappend
@@ -0,0 +1,9 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+COMPATIBLE_MACHINE_haswell-wc = "haswell-wc"
+KMACHINE_haswell-wc = "haswell-wc"
+KBRANCH_haswell-wc = "standard/base"
+
+LINUX_VERSION = "3.10.38"
+SRCREV_machine_haswell-wc = "02f7e63e56c061617957388c23bd5cf9b05c5388"
+SRCREV_meta_haswell-wc = "617c6158c3d5b931f0d6131e0b0a7b374c792599"


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

Re: [meta-intel] [PATCH 17/21] meta-crystalforest: Add linux-yocto_3.10 support

[Kamble, Nitin A]

Why are you not using the common kernel for this BSP?

Darren,
  Do you have more comments on this one?

Thanks,
Nitin

On 5/7/2014 5:19 PM, wei.sern.c...@intel.com wrote:

From: Chan Wei Sern 

Add linux-yocto_3.10 support on Intel CrystalForest
platform. KBRANCH is pointing to "standard/base" with
SRCREV_machine and SRCREV_meta point to 3.10.38.
Update LINUX_VERSION to reflect the 3.10.38 changes.

Signed-off-by: Chan Wei Sern 
---
  .../recipes-kernel/linux/linux-yocto_3.10.bbappend |   25 
  1 file changed, 25 insertions(+)
  create mode 100644 
meta-crystalforest/recipes-kernel/linux/linux-yocto_3.10.bbappend

diff --git a/meta-crystalforest/recipes-kernel/linux/linux-yocto_3.10.bbappend 
b/meta-crystalforest/recipes-kernel/linux/linux-yocto_3.10.bbappend
new file mode 100644
index 000..8a5f4a3
--- /dev/null
+++ b/meta-crystalforest/recipes-kernel/linux/linux-yocto_3.10.bbappend
@@ -0,0 +1,25 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+###
+# MACHINE = crystalforest-gladden #
+###
+COMPATIBLE_MACHINE_crystalforest-gladden = "crystalforest-gladden"
+KMACHINE_crystalforest-gladden  = "crystalforest"
+KBRANCH_crystalforest-gladden  = "standard/base"
+
+SRCREV_machine_crystalforest-gladden ?= 
"02f7e63e56c061617957388c23bd5cf9b05c5388"
+SRCREV_meta_crystalforest-gladden ?= "617c6158c3d5b931f0d6131e0b0a7b374c792599"
+
+##
+# MACHINE = crystalforest-server #
+##
+COMPATIBLE_MACHINE_crystalforest-server = "crystalforest-server"
+KMACHINE_crystalforest-server  = "crystalforest"
+KBRANCH_crystalforest-server  = "standard/base"
+
+SRCREV_machine_crystalforest-server ?= 
"02f7e63e56c061617957388c23bd5cf9b05c5388"
+SRCREV_meta_crystalforest-server ?= "617c6158c3d5b931f0d6131e0b0a7b374c792599"
+
+LINUX_VERSION = "3.10.38"
+
+module_autoload_uio = "uio"


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

Re: [meta-intel] [PATCH 18/21] meta-romley: Add linux-yocto_3.10 support

[Kamble, Nitin A]

Same comment as on the last commit.

Nitin

On 5/7/2014 5:19 PM, wei.sern.c...@intel.com wrote:

From: Chan Wei Sern 

Add linux-yocto_3.10 support on Intel Romley
platform. KBRANCH is pointing to "standard/base" with
SRCREV_machine and SRCREV_meta point to 3.10.38.
Update LINUX_VERSION to reflect the 3.10.38 changes.

Signed-off-by: Chan Wei Sern 
---
  .../recipes-kernel/linux/linux-yocto_3.10.bbappend |   25 
  1 file changed, 25 insertions(+)
  create mode 100644 meta-romley/recipes-kernel/linux/linux-yocto_3.10.bbappend

diff --git a/meta-romley/recipes-kernel/linux/linux-yocto_3.10.bbappend 
b/meta-romley/recipes-kernel/linux/linux-yocto_3.10.bbappend
new file mode 100644
index 000..c9fa530
--- /dev/null
+++ b/meta-romley/recipes-kernel/linux/linux-yocto_3.10.bbappend
@@ -0,0 +1,25 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+#
+# MACHINE = romley #
+#
+COMPATIBLE_MACHINE_romley = "romley"
+KMACHINE_romley  = "romley"
+KBRANCH_romley  = "standard/base"
+
+SRCREV_machine_romley ?= "02f7e63e56c061617957388c23bd5cf9b05c5388"
+SRCREV_meta_romley ?= "617c6158c3d5b931f0d6131e0b0a7b374c792599"
+
+#
+# MACHINE = romley-ivb #
+#
+COMPATIBLE_MACHINE_romley-ivb = "romley-ivb"
+KMACHINE_romley-ivb  = "romley"
+KBRANCH_romley-ivb  = "standard/base"
+
+SRCREV_machine_romley-ivb ?= "02f7e63e56c061617957388c23bd5cf9b05c5388"
+SRCREV_meta_romley-ivb ?= "617c6158c3d5b931f0d6131e0b0a7b374c792599"
+
+LINUX_VERSION = "3.10.38"
+
+module_autoload_uio = "uio"


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

Re: [meta-intel] [PATCH 16/21] meta-romley: remove using of intel-common-pkgarch.inc

[Kamble, Nitin A]

As comment as on the last commit.

Nitin

On 5/7/2014 5:19 PM, wei.sern.c...@intel.com wrote:

From: Chan Wei Sern 

Removed using of intel-common-pkgarch.inc in romley.conf
romley-ivb.conf. As we would like to have control over
preferred linux-yocto version for machine specific build.

Added PREFERRED_PROVIDER to it as well.

Signed-off-by: Chan Wei Sern 
---
  meta-romley/conf/machine/romley-ivb.conf |3 +--
  meta-romley/conf/machine/romley.conf |3 +--
  2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/meta-romley/conf/machine/romley-ivb.conf 
b/meta-romley/conf/machine/romley-ivb.conf
index af52897..32b1f6d 100644
--- a/meta-romley/conf/machine/romley-ivb.conf
+++ b/meta-romley/conf/machine/romley-ivb.conf
@@ -7,11 +7,10 @@
  #@DESCRIPTION: Machine configuration for Romley systems
  # i.e. Xeon E5-2600 and E5-2400 + Intel CC604/C602-J
  
-

+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
  PREFERRED_VERSION_linux-yocto ?= "3.10%"
  
  require conf/machine/include/intel-corei7-64-common.inc

-require conf/machine/include/intel-common-pkgarch.inc
  require conf/machine/include/meta-intel.inc
  
  XSERVER ?= "${XSERVER_X86_BASE} \

diff --git a/meta-romley/conf/machine/romley.conf 
b/meta-romley/conf/machine/romley.conf
index ed52a1e..6455e9e 100644
--- a/meta-romley/conf/machine/romley.conf
+++ b/meta-romley/conf/machine/romley.conf
@@ -7,11 +7,10 @@
  #@DESCRIPTION: Machine configuration for Romley systems
  # i.e. Xeon E5-2600 and E5-2400 + Intel CC604/C602-J
  
-

+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
  PREFERRED_VERSION_linux-yocto ?= "3.10%"
  
  require conf/machine/include/intel-corei7-64-common.inc

-require conf/machine/include/intel-common-pkgarch.inc
  require conf/machine/include/meta-intel.inc
  
  XSERVER ?= "${XSERVER_X86_BASE} \


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

Re: [meta-intel] [PATCH 15/21] meta-crystalforest: removed using of intel-common-pkgarch.inc

[Kamble, Nitin A]

This commit does not make sense. The purpose of pkgarch is to share the 
package architecture of kernel packages across different BSPs. It does 
not inhibit selection of preferred kernel version.


Darren,
  Do you have any further commit for this approach?

Thanks,
Nitin

On 5/7/2014 5:19 PM, wei.sern.c...@intel.com wrote:

From: Chan Wei Sern 

Removed using of intel-common-pkgarch.inc in
crystalforest-gladden.conf and crystalforest-server.conf.
As we would like to have control over preferred linux-yocto
version for machine specific build.

Signed-off-by: Chan Wei Sern 
---
  meta-crystalforest/conf/machine/crystalforest-gladden.conf |1 -
  meta-crystalforest/conf/machine/crystalforest-server.conf  |1 -
  2 files changed, 2 deletions(-)

diff --git a/meta-crystalforest/conf/machine/crystalforest-gladden.conf 
b/meta-crystalforest/conf/machine/crystalforest-gladden.conf
index 9c33293..c1b552a 100644
--- a/meta-crystalforest/conf/machine/crystalforest-gladden.conf
+++ b/meta-crystalforest/conf/machine/crystalforest-gladden.conf
@@ -12,7 +12,6 @@ PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
  PREFERRED_VERSION_linux-yocto ?= "3.10%"
  
  require conf/machine/include/intel-corei7-64-common.inc

-require conf/machine/include/intel-common-pkgarch.inc
  require conf/machine/include/meta-intel.inc
  
  XSERVER ?= "${XSERVER_X86_BASE} \

diff --git a/meta-crystalforest/conf/machine/crystalforest-server.conf 
b/meta-crystalforest/conf/machine/crystalforest-server.conf
index fd0e80a..7a5da09 100644
--- a/meta-crystalforest/conf/machine/crystalforest-server.conf
+++ b/meta-crystalforest/conf/machine/crystalforest-server.conf
@@ -12,7 +12,6 @@ PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
  PREFERRED_VERSION_linux-yocto ?= "3.10%"
  
  require conf/machine/include/intel-corei7-64-common.inc

-require conf/machine/include/intel-common-pkgarch.inc
  require conf/machine/include/meta-intel.inc
  
  XSERVER ?= "${XSERVER_X86_BASE} \


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

Re: [meta-intel] [PATCH 12/21] meta-valleyisland: new BSP layer for Intel Atom E38XX Processor

[Kamble, Nitin A]

On 5/7/2014 5:19 PM, wei.sern.c...@intel.com wrote:

From: Chan Wei Sern 

This layer provides support for Intel Atom E38XX Processor
product line.

Signed-off-by: Chan Wei Sern 
Signed-off-by: Chang Rebecca Swee Fun 
---
  meta-isg/meta-valleyisland/COPYING.MIT |   17 +++
  meta-isg/meta-valleyisland/README  |  218 
  meta-isg/meta-valleyisland/README.sources  |   18 +++
  meta-isg/meta-valleyisland/conf/layer.conf |   14 ++
  4 files changed, 267 insertions(+)
  create mode 100644 meta-isg/meta-valleyisland/COPYING.MIT
  create mode 100644 meta-isg/meta-valleyisland/README
  create mode 100644 meta-isg/meta-valleyisland/README.sources
  create mode 100644 meta-isg/meta-valleyisland/conf/layer.conf

diff --git a/meta-isg/meta-valleyisland/COPYING.MIT 
b/meta-isg/meta-valleyisland/COPYING.MIT
new file mode 100644
index 000..89de354
--- /dev/null
+++ b/meta-isg/meta-valleyisland/COPYING.MIT
@@ -0,0 +1,17 @@
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.
diff --git a/meta-isg/meta-valleyisland/README 
b/meta-isg/meta-valleyisland/README
new file mode 100644
index 000..014344b
--- /dev/null
+++ b/meta-isg/meta-valleyisland/README
@@ -0,0 +1,218 @@
+This README file contains information on building the meta-valleyisland
+BSP layer, and booting the images contained in the /binary directory.
+Please see the corresponding sections below for details.
+
+The Valley Island BSP consists of two versions:
+1. 32-bit Valley Island
+2. 64-bit Valley Island
+
+The BSP is made specifically for Intel Atom E38XX Processor E38XX
+Development Kit (formerly known as Valley Island). This BSP integrates
+Intel Graphics for Linux driver as the integrated graphics.
+
+Valley Island BSP is meant to support Valley Island Development
+Kit, "Bayley Bay" CRB and "Bakersport" CRB.
+
+Further information on the platforms supported by this BSP can be
+found here:
+
+  
http://www.intel.com/content/www/us/en/intelligent-systems/bay-trail/atom-processor-e3800-family-overview.html
+
+Information on all Intel® embedded platforms can be found here:
+
+  http://www.intel.com/p/en_US/embedded/hwsw/hardware
+
+Yocto Project Compatible
+
+
+This BSP is compatible with the Yocto Project as per the requirements
+listed here:
+
+  https://www.yoctoproject.org/webform/yocto-project-compatible-registration
+
+Dependencies
+
+
+This layer depends on:
+
+  URI: git://git.openembedded.org/bitbake
+  branch: master
+
+  URI: git://git.openembedded.org/openembedded-core
+  layers: meta
+  branch: dora
If this commit is for master branch, then it should not refer dora 
branch here.

+
+  URI: git://git.yoctoproject.org/meta-intel
+  layers: intel
+  branch: dora

Same comment as above.

Nitin


+
+Patches
+===
+
+Please submit any patches against this BSP to the Meta-Intel Yocto mailing list
+(meta-intel@yoctoproject.org) and cc: the maintainer:
+
+Maintainer: Chang Rebecca Swee Fun 
+
+Please see the meta-isg/MAINTAINERS file for more details.
+
+Table of Contents
+=
+
+  I. Building the meta-valleyisland BSP layer
+ II. Booting the images in /binary
+III. Device Notes
+ a. Boot Loader
+ b. I/O drivers
+ c. LPIO ACPI enumeration support
+ IV. Known Issues
+ a. I/O drivers
+
+
+I. Building the meta-valleyisland BSP layer
+===
+
+In order to build an image with BSP support for a given release, you
+need to download the corresponding BSP tarball from the 'Board Support
+Package (BSP) Downloads' page of the Yocto Project website.
+
+Having that done, and assuming you have extracted the BSP tarball contents
+at the top-level of your Yocto build tree, you can build a valleyisland
+image by adding the location of the meta-valleyisland layer to
+bblayers.conf, along with the meta-intel layer itself (to access
+common metadata shared between BSPs) e.g.:
+
+  yocto/meta-intel \
+  yocto/meta-intel/meta-isg/meta-valleyisland \
+
+To ena

Re: [meta-intel] [PATCH 11/21] meta-intel/common: Suppress canterbury corpus QA arch-check

[Kamble, Nitin A]

On 5/7/2014 5:19 PM, wei.sern.c...@intel.com wrote:

From: Ong Boon Leong 

'sum' is a SPARC executable bundled in canterbury corpus tarball.
By installing this file on x86 file-system, it results in QA
architecture-check warning. As the package is only meant for
compression benchmarking purpose, we would suppress the QA warning
check for architecture compatibility.

Can the 'sum' file be removed from install step instead?

Nitin



Signed-off-by: Ong Boon Leong 
---
  common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb |5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb 
b/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
index 93a1795..fbefea1 100644
--- a/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
+++ b/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
@@ -17,7 +17,10 @@ SRC_URI = 
"http://corpus.canterbury.ac.nz/resources/cantrbry.tar.gz";
  SRC_URI[md5sum] = "442e56cfffdf460d25b0b91650a55908"
  SRC_URI[sha256sum] = 
"f140e8a5b73d3f53198555a63bfb827889394a42f20825df33c810c3d5e3f8fb"
  
-WARN_QA += "arch"

+# Disable architecture QA check for this package since it contains
+# pre-compiled executable "sum" for SPARC. The package is used
+# for compression benchmarking only.
+WARN_QA += ""
  ERROR_QA = ""
  
  do_package_qa[noexec] = "1"


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

Re: [meta-intel] [PATCH 10/21] meta-intel/common: Update Canterbury Corpus do_install recipe

[Kamble, Nitin A]

On 5/7/2014 5:19 PM, wei.sern.c...@intel.com wrote:

From: Ong Boon Leong 

Fix do_install() issue caused by "patches" folder that is auto-generated
in do_unpack() step. Fix the issue by being explicitly listing out
the files in the canterbury corpus tarball.

Same comment as the one given on the last commit.
Nitin



Signed-off-by: Ong Boon Leong 
---
  .../canterbury-corpus/canterbury-corpus.bb |   20 +++-
  1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb 
b/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
index eb5afad..93a1795 100644
--- a/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
+++ b/common/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
@@ -29,7 +29,25 @@ do_unpack () {
  
  FILES_${PN} = "/lib/firmware/*"
  
+CORPUS_FILELIST=" \

+   alice29.txt \
+   asyoulik.txt \
+   cp.html \
+   fields.c \
+   grammar.lsp \
+   kennedy.xls \
+   lcet10.txt \
+   plrabn12.txt \
+   ptt5 \
+   sum \
+   xargs.1 \
+   "
+
  do_install () {
install -d ${D}${base_libdir}/firmware
-   install -m 644 ${S}/* ${D}${base_libdir}/firmware
+
+   for i in ${CORPUS_FILELIST}
+   do
+   install -m 644  ${S}/$i ${D}${base_libdir}/firmware
+   done
  }


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

Re: [meta-intel] [PATCH 09/21] meta-intel/common: Update Calgary Corpus do_install recipe

[Kamble, Nitin A]

On 5/7/2014 5:19 PM, wei.sern.c...@intel.com wrote:

From: Ong Boon Leong 

Fix do_install() issue caused by "patches" folder that is auto-generated
in do_unpack() step. Fix the issue by being explicitly listing out
the files in the calgary corpus tarball.

This will need updating everytime the filelist changes.
Instead can you use do_unpack_append()  to deal with the unwanted 
patches directory?


Nitin



Signed-off-by: Ong Boon Leong 
---
  .../calgary-corpus/calgary-corpus.bb   |   27 +++-
  1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/common/recipes-corpus/calgary-corpus/calgary-corpus.bb 
b/common/recipes-corpus/calgary-corpus/calgary-corpus.bb
index 5d2c66d..c7e6926 100644
--- a/common/recipes-corpus/calgary-corpus/calgary-corpus.bb
+++ b/common/recipes-corpus/calgary-corpus/calgary-corpus.bb
@@ -19,7 +19,32 @@ do_unpack () {
  
  FILES_${PN} = "/lib/firmware/*"
  
+CORPUS_FILELIST=" \

+   bib \
+   book1 \
+   book2 \
+   geo \
+   news \
+   obj1 \
+   obj2 \
+   paper1 \
+   paper2 \
+   paper3 \
+   paper4 \
+   paper5 \
+   paper6 \
+   pic \
+   progc \
+   progl \
+   progp \
+   trans \
+"
+
  do_install () {
install -d ${D}/lib/firmware
-   install -m 664 ${S}/* ${D}/lib/firmware
+
+   for i in ${CORPUS_FILELIST}
+   do
+   install -m 644  ${S}/$i ${D}/lib/firmware
+   done
  }


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

Re: [meta-intel] [PATCH 07/21] meta-mohonpeak: provide machine configuration for mohonpeak

[Kamble, Nitin A]

On 5/7/2014 5:19 PM, wei.sern.c...@intel.com wrote:

From: Chan Wei Sern 

Create new machines named 'mohonpeak32' and 'mohonpeak64'
for this platform.

Signed-off-by: Chan Wei Sern 
Signed-off-by: Ong Boon Leong 
---
  .../meta-mohonpeak/conf/machine/mohonpeak32.conf   |   21 
  .../meta-mohonpeak/conf/machine/mohonpeak64.conf   |   21 
  2 files changed, 42 insertions(+)
  create mode 100644 meta-isg/meta-mohonpeak/conf/machine/mohonpeak32.conf
  create mode 100644 meta-isg/meta-mohonpeak/conf/machine/mohonpeak64.conf

diff --git a/meta-isg/meta-mohonpeak/conf/machine/mohonpeak32.conf 
b/meta-isg/meta-mohonpeak/conf/machine/mohonpeak32.conf
new file mode 100644
index 000..c7bebba
--- /dev/null
+++ b/meta-isg/meta-mohonpeak/conf/machine/mohonpeak32.conf
@@ -0,0 +1,21 @@
+#@TYPE: Machine
+#@NAME: mohonpeak 32bit
+
+#@DESCRIPTION: Machine configuration for Mohon Peak systems
+
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+PREFERRED_VERSION_linux-yocto ?= "3.10%"

Why are you not using the latest v3.14 kernel here?

Nitin


+
+require conf/machine/include/intel-core2-32-common.inc
+require conf/machine/include/meta-intel.inc
+
+XSERVER ?= "${XSERVER_X86_BASE} \
+  ${XSERVER_X86_EXT} \
+  ${XSERVER_X86_ASPEED_AST} \
+   "
+
+MACHINE_FEATURES += "pcbios efi"
+
+SYSLINUX_OPTS = "serial 1 115200"
+SERIAL_CONSOLE = "115200 ttyS1"
+APPEND += "console=ttyS1,115200 console=tty1"
diff --git a/meta-isg/meta-mohonpeak/conf/machine/mohonpeak64.conf 
b/meta-isg/meta-mohonpeak/conf/machine/mohonpeak64.conf
new file mode 100644
index 000..5dc96e8
--- /dev/null
+++ b/meta-isg/meta-mohonpeak/conf/machine/mohonpeak64.conf
@@ -0,0 +1,21 @@
+#@TYPE: Machine
+#@NAME: mohonpeak 64 bit
+
+#@DESCRIPTION: Machine configuration for Mohon Peak systems
+
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+PREFERRED_VERSION_linux-yocto ?= "3.10%"
+
+require conf/machine/include/intel-corei7-64-common.inc
+require conf/machine/include/meta-intel.inc
+
+XSERVER ?= "${XSERVER_X86_BASE} \
+  ${XSERVER_X86_EXT} \
+  ${XSERVER_X86_ASPEED_AST} \
+   "
+
+MACHINE_FEATURES += "pcbios efi"
+
+SYSLINUX_OPTS = "serial 1 115200"
+SERIAL_CONSOLE = "115200 ttyS1"
+APPEND += "console=ttyS1,115200 console=tty1"


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