Re: [meta-intel] [PATCH 1/2] linux-intel-rt/4.14: update to v4.14.34

[Cal Sullivan]

These are backports to rocko. I just forgot to add the tag.

---
Cal

On 05/03/2018 01:07 PM, California Sullivan wrote:

Also updates preempt-rt patchset to -rt27.

Change from branch 4.14/yocto/base-rt to 4.14/base-rt. This is only
cosmetic, the branches are exactly the same.

Signed-off-by: California Sullivan 
(cherry picked from commit 85a301575da7e9b76815b363087d93fbbeb1f6e8)
Signed-off-by: California Sullivan 
---
  common/recipes-kernel/linux/linux-intel-rt_4.14.bb | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/recipes-kernel/linux/linux-intel-rt_4.14.bb 
b/common/recipes-kernel/linux/linux-intel-rt_4.14.bb
index 5420e3e0..d4b02986 100644
--- a/common/recipes-kernel/linux/linux-intel-rt_4.14.bb
+++ b/common/recipes-kernel/linux/linux-intel-rt_4.14.bb
@@ -9,7 +9,7 @@ python () {
  raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-intel-rt to enable it")
  }
  
-KBRANCH = "4.14/yocto/base-rt"

+KBRANCH = "4.14/preempt-rt"
  KMETA_BRANCH = "yocto-4.14"
  
  # Fix for 32-bit perf issue. Remove when patch is backported to 4.14.

@@ -17,8 +17,8 @@ SRC_URI_append = " 
file://0001-perf-x86-32-explicitly-include-errno.h.patch"
  
  DEPENDS += "elfutils-native openssl-native util-linux-native"
  
-LINUX_VERSION ?= "4.14.29"

-SRCREV_machine ?= "c580716ae72c2bcb2202641e69e1b72d01ee4581"
+LINUX_VERSION ?= "4.14.34"
+SRCREV_machine ?= "c40b54f7eae42ac6ef28b324900c1c99e719e449"
  SRCREV_meta ?= "245d701df6c3691a078a268eff54009959beb842"
  
  LINUX_KERNEL_TYPE = "preempt-rt"


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

Re: [meta-intel] [meta-dpdk 0/3] dpdk: Add support for arm64

[Cal Sullivan]

Merged. Worth noting is that 2/3 revealed an error in meta-intel's 
DPDK_TARGET_MACHINE setting and intel-corei7-64's build will be broken 
for a day or so while a proper default is decided.


I'll also backport that default to rocko when its fixed.

Thanks,
Cal

On 04/12/2018 10:06 PM, Kevin Hao wrote:

Hi,

This patch series adds the arm64 support for dpdk. This has passed build
test on x86-64 and arm64. For arm64 build, you need to enable the
CONFIG_PCI for kernel and add something like follow in your local.conf:
 COMPATIBLE_MACHINE_pn-dpdk = "qemuarm64"
 COMPATIBLE_MACHINE_pn-dpdk-dev-libibverbs = "qemuarm64"
 COMPATIBLE_HOST_pn-dpdk-dev-libibverbs = '(aarch64).*-linux'
 DPDK_TARGET_MACHINE ?= "dpaa2"


Kevin Hao (3):
   dpdk: Remove the useless checksums
   dpdk: Add the missing return in get_dpdk_target_mach()
   dpdk: Add support for arm64

  recipes-extended/dpdk/dpdk.inc| 11 +++
  recipes-extended/dpdk/dpdk_17.11.1.bb |  3 ---
  recipes-extended/dpdk/dpdk_18.02.bb   |  3 ---
  3 files changed, 7 insertions(+), 10 deletions(-)



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

Re: [meta-intel] [PATCH 1/3] linux-intel/4.9: update to v4.9.84

[Cal Sullivan]

Upon further testing, this patch has introduced a kernel BUG and likely 
hang with the -rt version and will not be merged. The others are still good.


---
Cal

On 04/12/2018 04:24 PM, California Sullivan wrote:

Update from v4.9.81 stable to v4.9.84 stable.

Signed-off-by: California Sullivan 
---
  recipes-kernel/linux/linux-intel-rt_4.9.bb | 4 ++--
  recipes-kernel/linux/linux-intel_4.9.bb| 4 ++--
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-kernel/linux/linux-intel-rt_4.9.bb 
b/recipes-kernel/linux/linux-intel-rt_4.9.bb
index b09c5bd3..343a54a1 100644
--- a/recipes-kernel/linux/linux-intel-rt_4.9.bb
+++ b/recipes-kernel/linux/linux-intel-rt_4.9.bb
@@ -13,8 +13,8 @@ python () {
  KBRANCH = "4.9/yocto/base-rt"
  KMETA_BRANCH = "yocto-4.9"
  
-LINUX_VERSION ?= "4.9.81"

-SRCREV_machine ?= "5a78c84100e737140558a3ef3e22e5a9380e8589"
+LINUX_VERSION ?= "4.9.84"
+SRCREV_machine ?= "2db6fab81cddb67f3bae6202cbf9169e7822fb35"
  SRCREV_meta ?= "a2dfb1610d9dad34652a3c27c6c9d8751ed67af6"
  
  LINUX_KERNEL_TYPE = "preempt-rt"

diff --git a/recipes-kernel/linux/linux-intel_4.9.bb 
b/recipes-kernel/linux/linux-intel_4.9.bb
index 69f76551..db30f1ff 100644
--- a/recipes-kernel/linux/linux-intel_4.9.bb
+++ b/recipes-kernel/linux/linux-intel_4.9.bb
@@ -4,8 +4,8 @@ require linux-intel.inc
  KBRANCH = "4.9/yocto/base"
  KMETA_BRANCH = "yocto-4.9"
  
-LINUX_VERSION ?= "4.9.81"

-SRCREV_machine ?= "c249d8e0ca9fef0ace933f1ef21d514b5915d783"
+LINUX_VERSION ?= "4.9.84"
+SRCREV_machine ?= "32f1da9a7c26c17c79f8e08683afa580dc3e12cb"
  SRCREV_meta ?= "a2dfb1610d9dad34652a3c27c6c9d8751ed67af6"
  
  # For Crystalforest and Romley


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

Re: [meta-intel] [meta-dpdk 4/4] dpdk: Refresh the patches for the context changes

[Cal Sullivan]

It looks like dpdk-16.04-Fix-for-misleading-indentation-error.patch is 
no longer necessary, as they added braces upstream.


Otherwise, this set looks good and builds fine.

I'll merge this and send an additional patch removing 
dpdk-16.04-Fix-for-misleading-indentation-error.patch.


Thanks,
Cal

On 04/08/2018 05:23 AM, Kevin Hao wrote:

Using the following commands to refresh the patches in order to
suppress the fuzz warnings.
   devtool modify dpdk
   devtool finish --force-patch-refresh dpdk meta-dpdk-dir

No code change.

Signed-off-by: Kevin Hao 
---
  ...-examples-Fix-maybe-uninitialized-warning.patch | 14 +--
  ...6.04-Fix-for-misleading-indentation-error.patch | 28 ++
  ...-add-RTE_KERNELDIR_OUT-to-split-kernel-bu.patch | 14 +--
  ...le-ip_fragmentation-in-common_base-config.patch | 16 ++---
  ...07-add-sysroot-option-within-app-makefile.patch | 12 --
  ...dk-16.07-dpdk-fix-for-parellel-make-issue.patch | 16 ++---
  ...2-dpdk-fix-installation-warning-and-issue.patch |  8 +++
  7 files changed, 47 insertions(+), 61 deletions(-)

diff --git 
a/recipes-extended/dpdk/dpdk/0001-examples-Fix-maybe-uninitialized-warning.patch
 
b/recipes-extended/dpdk/dpdk/0001-examples-Fix-maybe-uninitialized-warning.patch
index cc8041e79e73..2facd39dcaca 100644
--- 
a/recipes-extended/dpdk/dpdk/0001-examples-Fix-maybe-uninitialized-warning.patch
+++ 
b/recipes-extended/dpdk/dpdk/0001-examples-Fix-maybe-uninitialized-warning.patch
@@ -1,4 +1,4 @@
-From 3924f5df5aca5ba23abbe9a84173280ede8be2dd Mon Sep 17 00:00:00 2001
+From 41ac64efa5050430b73e0f8813dffc7327083273 Mon Sep 17 00:00:00 2001
  From: Khem Raj 
  Date: Tue, 1 Aug 2017 20:18:46 -0700
  Subject: [PATCH] examples: Fix maybe-uninitialized warning
@@ -8,16 +8,17 @@ Initialize arrays to 0, makes compiler happy about
  error: 'vals[0]' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
  
  Signed-off-by: Khem Raj 

+
  ---
   examples/qos_sched/args.c   | 2 +-
   examples/vhost/virtio_net.c | 2 +-
   2 files changed, 2 insertions(+), 2 deletions(-)
  
  diff --git a/examples/qos_sched/args.c b/examples/qos_sched/args.c

-index 476a0ee..fd601c3 100644
+index 83eee95cc28e..3d2c0fbd6d0a 100644
  --- a/examples/qos_sched/args.c
  +++ b/examples/qos_sched/args.c
-@@ -241,7 +241,7 @@ static int
+@@ -212,7 +212,7 @@ static int
   app_parse_flow_conf(const char *conf_str)
   {
int ret;
@@ -27,10 +28,10 @@ index 476a0ee..fd601c3 100644
uint64_t mask;
   
  diff --git a/examples/vhost/virtio_net.c b/examples/vhost/virtio_net.c

-index cc2c3d8..16b5392 100644
+index f6e00674d9af..a4a90704d7b4 100644
  --- a/examples/vhost/virtio_net.c
  +++ b/examples/vhost/virtio_net.c
-@@ -327,7 +327,7 @@ vs_dequeue_pkts(struct vhost_dev *dev, uint16_t queue_id,
+@@ -293,7 +293,7 @@ vs_dequeue_pkts(struct vhost_dev *dev, uint16_t queue_id,
   {
struct vhost_queue *queue;
struct rte_vhost_vring *vr;
@@ -39,6 +40,3 @@ index cc2c3d8..16b5392 100644
uint32_t used_idx;
uint32_t i = 0;
uint16_t free_entries;
---
-2.13.3
-
diff --git 
a/recipes-extended/dpdk/dpdk/dpdk-16.04-Fix-for-misleading-indentation-error.patch
 
b/recipes-extended/dpdk/dpdk/dpdk-16.04-Fix-for-misleading-indentation-error.patch
index 8786af7ced41..78283336d23c 100644
--- 
a/recipes-extended/dpdk/dpdk/dpdk-16.04-Fix-for-misleading-indentation-error.patch
+++ 
b/recipes-extended/dpdk/dpdk/dpdk-16.04-Fix-for-misleading-indentation-error.patch
@@ -1,4 +1,4 @@
-From 8cd0a16af531cca0af6b4f9b729c252b8bdbf8e2 Mon Sep 17 00:00:00 2001
+From e7df50cd214e30741a4594c1fb969baa7574c303 Mon Sep 17 00:00:00 2001
  From: Rahul Kumar Gupta 
  Date: Tue, 5 Jul 2016 00:05:25 +0800
  Subject: [PATCH] Fix for misleading indentation error
@@ -7,18 +7,19 @@ fix the indentation of the code to match the block structure. 
This may cause
  build errors if you have -Wall -Werror in your project.
  
  Signed-off-by: Rahul Kumar Gupta 

+
  ---
   lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c | 8 
   lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c | 2 +-
   2 files changed, 5 insertions(+), 5 deletions(-)
  
  diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c b/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c

-index df22470..ba28eba 100644
+index 1934a309cda4..58ed65f062ae 100644
  --- a/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c
  +++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_phy.c
-@@ -3302,8 +3302,8 @@ s32 e1000_read_phy_reg_mphy(struct e1000_hw *hw, u32 
address, u32 *data)
+@@ -3287,8 +3287,8 @@ s32 e1000_read_phy_reg_mphy(struct e1000_hw *hw, u32 
address, u32 *data)
/* Disable access to mPHY if it was originally disabled */
-   if (locked)
+   if (locked) {
ready = e1000_is_mphy_ready(hw);
  - if (!ready)
  - return -E1000_ERR_PHY;
@@ -26,10 +27,10 @@ index df22470..ba28eba 100644
  +  

Re: [meta-intel] [meta-dpdk][PATCH] dpdk.inc: fix missing numa.h by disabling NUMA options by default

[Cal Sullivan]

Thanks for the feedback. v2 has been sent. Assuming no other issues are 
found I'll merge tomorrow. Apologies for the delays.


Thanks,
Cal

On 04/01/2018 10:37 PM, Belal, Awais wrote:

+PACKAGECONFIG[libnuma] = ",,libnuma"

This dependency should be on 'numactl' which is provided under meta-oe and the 
PACKAGECONFIG should use just numa rather than libnuma IMO.

BR,
Awais


From: California Sullivan 
Sent: Saturday, March 31, 2018 2:29 AM
To: meta-intel@yoctoproject.org
Cc: kexin@windriver.com; Belal, Awais; California Sullivan
Subject: [meta-dpdk][PATCH] dpdk.inc: fix missing numa.h by disabling NUMA 
options by default

Otherwise we get this:

| dpdk-18.02/lib/librte_eal/linuxapp/eal/eal_memory.c:27:10: fatal error: 
numa.h: No such file or directory
|  #include 
|   ^~~~
| compilation terminated.

Signed-off-by: California Sullivan 
---
Based on top of Awais's patch "dpdk: upgrade to 18.02"

  recipes-extended/dpdk/dpdk.inc | 4 
  1 file changed, 4 insertions(+)

diff --git a/recipes-extended/dpdk/dpdk.inc b/recipes-extended/dpdk/dpdk.inc
index ce4e8bc..9affda4 100644
--- a/recipes-extended/dpdk/dpdk.inc
+++ b/recipes-extended/dpdk/dpdk.inc
@@ -29,10 +29,12 @@ COMPATIBLE_HOST_libc-musl_class-target = "null"
  PACKAGECONFIG[dpdk_qat] = ",,virtual/qat"
  PACKAGECONFIG[vhost] = ",,fuse"
  PACKAGECONFIG[libvirt] = ",,libvirt"
+PACKAGECONFIG[libnuma] = ",,libnuma"

  export CONFIG_EXAMPLE_DPDK_QAT = "${@bb.utils.contains('PACKAGECONFIG', 
'dpdk_qat', 'y', 'n', d)}"
  export CONFIG_EXAMPLE_VM_POWER_MANAGER = "${@bb.utils.contains('PACKAGECONFIG', 
'libvirt', 'y', 'n', d)}"
  export CONFIG_VHOST_ENABLED = "${@bb.utils.contains('PACKAGECONFIG', 'vhost', 'y', 
'n', d)}"
+export CONFIG_VHOST_NUMA_ENABLED = "${@bb.utils.contains('PACKAGECONFIG', 
'libnuma', 'y', 'n', d)}"

  RDEPENDS_${PN} += "python-subprocess virtual/libibverbs"
  DEPENDS = "virtual/kernel virtual/libibverbs"
@@ -80,6 +82,8 @@ do_configure () {
 sed -e 
"s#CONFIG_RTE_KNI_VHOST=n#CONFIG_RTE_KNI_VHOST=${CONFIG_VHOST_ENABLED}#" -i 
${S}/config/common_linuxapp
 sed -e 
"s#CONFIG_RTE_KNI_VHOST_VNET_HDR_EN=n#CONFIG_RTE_KNI_VHOST_VNET_HDR_EN=${CONFIG_VHOST_ENABLED}#"
 -i ${S}/config/common_linuxapp
 sed -e 
"s#CONFIG_RTE_LIBRTE_VHOST=n#CONFIG_RTE_LIBRTE_VHOST=${CONFIG_VHOST_ENABLED}#" 
-i ${S}/config/common_linuxapp
+   sed -e 
"s#CONFIG_RTE_LIBRTE_VHOST_NUMA=.*#CONFIG_RTE_LIBRTE_VHOST_NUMA=${CONFIG_VHOST_NUMA_ENABLED}#"
 -i ${S}/config/common_linuxapp
+   sed -e 
"s#CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=.*#CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=${CONFIG_VHOST_NUMA_ENABLED}#"
 -i ${S}/config/common_linuxapp

 make O=$RTE_TARGET T=$RTE_TARGET config
  }
--
2.14.3



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

Re: [meta-intel] [meta-dpdk][PATCH 2/2] dpdk: merge recipe and include

[Cal Sullivan]

Hi Awais, Kevin,

In testing I ran into some compilation problems: 
https://pastebin.com/n8dhUmZT


I was able to fix it by disabling some options, but I don't know the 
ramifications of these changes.
In working on this I noticed most of the sed commands in that 
do_configure block could use a review, as some are trying to modify 
options that no longer exist there, and others assume =n in the string 
to replace.


Could one of you review my patch and maybe take a look at the configure 
block as a whole?


Thanks,
Cal

On 03/29/2018 11:36 PM, Belal, Awais wrote:

Do we know when this will be merged?

BR,
Awais


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

Re: [meta-intel] Unable to install the image on the hard disk

[Cal Sullivan]

Generally a .wic image is intended to be installed directly to its final 
destination, whereas an hddimg is for evaluation and installation elsewhere.


By default meta-intel .wic images only have an EFI bootloader, and will 
not boot via legacy BIOS.


An hddimg will have both an EFI bootloader and the syslinux binaries 
that let it boot from legacy BIOS.


On startup with your installer USB image do you get a light gray screen 
with four options? If so it is booting via legacy BIOS.


Are you able to get to an EFI shell? It may be worth poking around 
there. At the very least to make sure there is an fs0: that contains a 
bootx64.efi under the /EFI/BOOT/ directory. If that isn't there then 
your firmware isn't seeing the SSD at all for some reason.


Thanks,

Cal


On 03/28/2018 06:29 PM, Mohammad, Jamal M wrote:


It’s EFI, Doesn’t work with Legacy, since it has bootx64.efi in the 
first partition.


What is the difference between .hddimg and .wic format.

*From:*Cal Sullivan [mailto:california.l.sulli...@intel.com]
*Sent:* Thursday, March 29, 2018 12:09 AM
*To:* Mohammad, Jamal M ; 
meta-intel@yoctoproject.org

*Subject:* Re: [meta-intel] Unable to install the image on the hard disk

Does your board startup via EFI or legacy BIOS? Try toggling it if you 
can.


Thanks,
Cal

On 03/27/2018 11:03 PM, Mohammad, Jamal M wrote:

Hi Guys,

1.Created an minimal yocto image using "bitbake
core-image-minimal" command

 2. Flashed the USB using the dd command.

sudo dd

if=tmp/deploy/images/intel-corei7-64/core-image-minimal-intel-corei7-64.hddimg
of=/dev/sdb

3.Clicked on install and typed “sda”

4.The installation was successful and when I tried to restart by
removing the USB Drive, it says “No boot options found. Please
install bootable media and restart."

What is the mistake I am doing here.

If I boot from USB, it works and there is no issue, I am able to
login into the system. Also after flashing I checked the sda1 sda2
with bootable USB, sda1 has boot partition and sda2 has root
partition..

I am trying this on Braswell based board ( Intel Celeron N3160 )

Thanks and Regards,

Jamal





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

Re: [meta-intel] Unable to install the image on the hard disk

[Cal Sullivan]

Does your board startup via EFI or legacy BIOS? Try toggling it if you can.

Thanks,
Cal

On 03/27/2018 11:03 PM, Mohammad, Jamal M wrote:


Hi Guys,

1.Created an minimal yocto image using "bitbake core-image-minimal" 
command


 2. Flashed the USB using the dd command.

sudo dd 
if=tmp/deploy/images/intel-corei7-64/core-image-minimal-intel-corei7-64.hddimg 
of=/dev/sdb


3.Clicked on install and typed “sda”

4.The installation was successful and when I tried to restart by 
removing the USB Drive, it says “No boot options found. Please install 
bootable media and restart."


What is the mistake I am doing here.

If I boot from USB, it works and there is no issue, I am able to login 
into the system. Also after flashing I checked the sda1 sda2 with 
bootable USB, sda1 has boot partition and sda2 has root partition..


I am trying this on Braswell based board ( Intel Celeron N3160 )

Thanks and Regards,

Jamal





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

Re: [meta-intel] [meta-dpdk][PATCH 2/2] dpdk: merge recipe and include

[Cal Sullivan]

Is patch 1/2 good to merge?

It looks like in order for 18.02 and 17.11 to use the same .inc file we 
will need to move the LIC_FILES_CHKSUM out of it, but that can be done 
later. 17.11 seems to have upstreamed the same patch that was dropped in 
this upgrade, so we're good on that front as well.


Thanks,
Cal

On 03/28/2018 12:46 AM, Kevin Hao wrote:

On Wed, Mar 28, 2018 at 12:27:48PM +0500, Awais Belal wrote:

Since we only have a single version supported at the
moment, which is the latest and the greatest. It is
best that the include and base recipe files are merged
to allow better maintainability and readability.

Please don't do this because I plan to add the 17.11 (LTS) version to the Yocto.

Thanks,
Kevin


Signed-off-by: Awais Belal 
---
  recipes-extended/dpdk/dpdk.inc  | 167 --
  recipes-extended/dpdk/dpdk_18.02.bb | 175 ++--
  2 files changed, 167 insertions(+), 175 deletions(-)
  delete mode 100644 recipes-extended/dpdk/dpdk.inc

diff --git a/recipes-extended/dpdk/dpdk.inc b/recipes-extended/dpdk/dpdk.inc
deleted file mode 100644
index ce4e8bc..000
--- a/recipes-extended/dpdk/dpdk.inc
+++ /dev/null
@@ -1,167 +0,0 @@
-DESCRIPTION = "Intel(r) Data Plane Development Kit"
-HOMEPAGE = "http://dpdk.org";
-LICENSE = "BSD & LGPLv2 & GPLv2"
-LIC_FILES_CHKSUM = 
"file://license/gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
-
file://license/lgpl-2.1.txt;md5=4b54a1fd55a448865a0b32d41598759d \
-
file://license/bsd-3-clause.txt;md5=0f00d99239d922ffd13cabef83b33444"
-
-SRC_URI = "http://fast.dpdk.org/rel/${BP}.tar.gz;name=dpdk \
-  file://dpdk-16.04-add-RTE_KERNELDIR_OUT-to-split-kernel-bu.patch \
-  file://dpdk-16.07-add-sysroot-option-within-app-makefile.patch \
-  file://dpdk-16.04-Fix-for-misleading-indentation-error.patch \
-  file://dpdk-16.07-dpdk-fix-for-parellel-make-issue.patch \
-  file://dpdk-17.02-dpdk-fix-installation-warning-and-issue.patch \
- "
-
-# A machine needs to enable this using:
-# COMPATIBLE_MACHINE_pn-dpdk-dev-libibverbs = ""
-
-COMPATIBLE_MACHINE = "null"
-COMPATIBLE_HOST_libc-musl_class-target = "null"
-
-
-# dpdk example apps dpdk_qat and vhost have dependancy on fuse and qat.
-# fuse is in meta-filesystems and qat is not yet upstreamed.
-# So adding mechanism to explicitly disable the use of fuse and qat.
-# To enable, uncomment the below line or include in .bbappend.
-# PACKAGECONFIG ?= " dpdk_qat vhost libvirt"
-
-PACKAGECONFIG[dpdk_qat] = ",,virtual/qat"
-PACKAGECONFIG[vhost] = ",,fuse"
-PACKAGECONFIG[libvirt] = ",,libvirt"
-
-export CONFIG_EXAMPLE_DPDK_QAT = "${@bb.utils.contains('PACKAGECONFIG', 'dpdk_qat', 
'y', 'n', d)}"
-export CONFIG_EXAMPLE_VM_POWER_MANAGER = "${@bb.utils.contains('PACKAGECONFIG', 
'libvirt', 'y', 'n', d)}"
-export CONFIG_VHOST_ENABLED = "${@bb.utils.contains('PACKAGECONFIG', 'vhost', 'y', 
'n', d)}"
-
-RDEPENDS_${PN} += "python-subprocess virtual/libibverbs"
-DEPENDS = "virtual/kernel virtual/libibverbs"
-do_configure[depends] += "virtual/kernel:do_shared_workdir"
-
-inherit module
-
-export MODULE_DIR="/lib/modules/${KERNEL_VERSION}/kernel/drivers/net"
-export RTE_SDK = "${S}"
-export RTE_TARGET="${@bb.utils.contains("TUNE_FEATURES", "m64", "x86_64-native-linuxapp-gcc", 
"i686-native-linuxapp-gcc", d)}"
-
-export ICP_ROOT = "${PKG_CONFIG_SYSROOT_DIR}/usr/include"
-export ICP_LIB_ROOT= "${PKG_CONFIG_SYSROOT_DIR}/usr/lib"
-export RTE_KERNELDIR = "${STAGING_KERNEL_DIR}"
-export RTE_KERNELDIR_OUT = "${STAGING_KERNEL_BUILDDIR}"
-export INSTALL_PATH = "${prefix}/share"
-export RTE_OUTPUT = "${S}/${RTE_TARGET}"
-export ETHTOOL_LIB_PATH = "${S}/examples/ethtool/lib/${RTE_TARGET}/"
-export SYSROOTPATH = "--sysroot=${STAGING_DIR_HOST}"
-export DPDK_TARGET_MACH = "${@get_dpdk_target_mach(bb,d)}"
-export ICP_LAC_API_DIR = "${STAGING_DIR_TARGET}${includedir}/lac"
-
-# The list of intel Comms platforms and their target machine
-# process mapping. The supported target machine is listed under
-# dpdk/mk/machine
-def get_dpdk_target_mach(bb, d):
-target_arch = d.getVar('DPDK_TARGET_MACHINE', True)
-if target_arch:
-target_arch
-return "default"
-
-do_configure () {
-   #
-   ### default value for prefix is "usr", unsetting it, so it
-   ### will not be concatenated in ${RTE_TARGET}/Makefile
-   ### which will cause compilation failure
-   #
-   unset prefix
-
-   # Fix-up CONFIG_RTE_MACHINE based on target machine
-   sed -e 
"s#CONFIG_RTE_MACHINE=\"native\"#CONFIG_RTE_MACHINE=\"${DPDK_TARGET_MACH}\"#" 
-i ${S}/config/defconfig_x86_64-native-linuxapp-gcc
-   sed -e 
"s#CONFIG_RTE_MACHINE=\"native\"#CONFIG_RTE_MACHINE=\"${DPDK_TARGET_MACH}\"#" 
-i ${S}/config/defconfig_i686-native-linuxapp-gcc
-
-   # Fix-up vhost configs 

Re: [meta-intel] outdated dpdk-dev-libibverbs

[Cal Sullivan]

Nevermind, I see you figured it out!

Thanks,
Cal

On 03/14/2018 11:14 AM, Cal Sullivan wrote:
Hmm, I'm not sure. Are you subscribed to the list? IIRC I had to 
manually approve your initial mail. Could be related.


Thanks,
Cal

On 03/14/2018 04:01 AM, Belal, Awais wrote:


Hi Cal,


Thanks a lot for the reply.


>> If you (or any other users of meta-intel-dpdk on the list) could 
test using upstream libibverbs it would be much appreciated. I could 
then fix it >> to use upstream libibverbs or take a patch for it.



I'll have a look in near future hopefully.


Right now I am trying to send a patch to meta-intel@yoctoproject.org 
using git send-email but it is failing with "550 5.7.1 Unable to 
relay", any pointers?



BR,
/Awais/
--------
*From:* Cal Sullivan 
*Sent:* Saturday, March 10, 2018 4:17 AM
*To:* Belal, Awais; meta-intel@yoctoproject.org
*Subject:* Re: [meta-intel] outdated dpdk-dev-libibverbs
Hi Awais,

I don't know the history of why that version of libibverbs was used 
instead. Considering it no longer exists, I agree that it should be 
changed. Unfortunately I don't have any experience and likely lack 
the hardware for using dpdk, so I can only go as far as making sure 
it builds OK.


If you (or any other users of meta-intel-dpdk on the list) could test 
using upstream libibverbs it would be much appreciated. I could then 
fix it to use upstream libibverbs or take a patch for it.


Thanks,
Cal

On 03/09/2018 03:02 AM, Belal, Awais wrote:


Hi,


I was going through the meta-dpdk layer () and the actual dpdk 
package depends on dpdk-dev-libibverbs. Now, looking at the recipe 
for dpdk-dev-libibverbs it uses and outdated SRC_URI for fetching 
the sources (the actual tarball pointed to:  does not exist) and the 
yocto mirror is used to fetch the tarball instead. Are there any 
plans of fixing/updating this? Why isn't this using a generic 
libibverbs source?



BR,
/Awais/










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

Re: [meta-intel] outdated dpdk-dev-libibverbs

[Cal Sullivan]

Hmm, I'm not sure. Are you subscribed to the list? IIRC I had to 
manually approve your initial mail. Could be related.


Thanks,
Cal

On 03/14/2018 04:01 AM, Belal, Awais wrote:


Hi Cal,


Thanks a lot for the reply.


>> If you (or any other users of meta-intel-dpdk on the list) could 
test using upstream libibverbs it would be much appreciated. I could 
then fix it >> to use upstream libibverbs or take a patch for it.



I'll have a look in near future hopefully.


Right now I am trying to send a patch to meta-intel@yoctoproject.org 
using git send-email but it is failing with "550 5.7.1 Unable to 
relay", any pointers?



BR,
/Awais/
--------
*From:* Cal Sullivan 
*Sent:* Saturday, March 10, 2018 4:17 AM
*To:* Belal, Awais; meta-intel@yoctoproject.org
*Subject:* Re: [meta-intel] outdated dpdk-dev-libibverbs
Hi Awais,

I don't know the history of why that version of libibverbs was used 
instead. Considering it no longer exists, I agree that it should be 
changed. Unfortunately I don't have any experience and likely lack the 
hardware for using dpdk, so I can only go as far as making sure it 
builds OK.


If you (or any other users of meta-intel-dpdk on the list) could test 
using upstream libibverbs it would be much appreciated. I could then 
fix it to use upstream libibverbs or take a patch for it.


Thanks,
Cal

On 03/09/2018 03:02 AM, Belal, Awais wrote:


Hi,


I was going through the meta-dpdk layer () and the actual dpdk 
package depends on dpdk-dev-libibverbs. Now, looking at the recipe 
for dpdk-dev-libibverbs it uses and outdated SRC_URI for fetching the 
sources (the actual tarball pointed to:  does not exist) and the 
yocto mirror is used to fetch the tarball instead. Are there any 
plans of fixing/updating this? Why isn't this using a generic 
libibverbs source?



BR,
/Awais/






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

Re: [meta-intel] galileo

[Cal Sullivan]

Adding Stephano to CC. He's recently played with a Galileo and I think 
he got some of the stuff you're asking about to work on the 4.14 kernel.


A couple responses inline below...

On 03/11/2018 02:10 PM, Trevor Woerner wrote:

Hi,

I realize that the Galileo board has been completely abandoned; I'm 
not looking for "official" information, but I'm hoping someone would 
be willing to provide some anecdotal information... perhaps offline?


I thought it would be a fun exercise to investigate updating the Linux 
image and arduino-IDE-toolchain for my Galileo Gen2 board. 
Unfortunately I've hit some walls and was looking for some ideas.


With its LOCKing problem[*1], projects like Yocto and Buildroot are 
natural homes for Galileo support. It looks as though Galileo support 
was added to The Yocto Project somewhere around Dylan [1.4] with 
https://github.com/intel/Galileo-Runtime.git. Using the 
sub-repositories found there and a virtual machine I'm able to build a 
working toolchain which I can install in my Arduino 1.8.5 IDE to 
build, upload, and run Blink. I can also build a rootfs image, but 
there isn't much in the way of guidance on how to get the resulting 
artifacts cobbled together onto an SDcard. But if I leave the SDcard 
slot empty, I can boot the default flash image that was shipped with 
the board (which is based on Dylan), and the IDE and sketches all 
work[*2].


After Dylan, Galileo-Runtime.git appears to have been abandoned (it's 
still stuck at Dylan) and meta-intel-quark and meta-intel-galileo 
appear... for Daisy [1.6]. Building with these layers (with everything 
setup for Daisy) doesn't work out-of-the-box due to some complaining 
about circular dependencies of initscripts on initscripts. I've tried 
several different things and combinations, but I can't successfully 
build an image or toolchain using these layers. These layers also have 
Dizzy [1.7] branches, so I gave those a whirl too without any success 
either.


After Dizzy, meta-intel-quark and meta-intel-galileo appear to have 
been abandoned and Quark/Galileo support migrated to meta-intel (and 
was subsequently removed after Rocko [2.4]). Along that path, the 
bootloader moved from grub0 to gummiboot to systemd-boot. The 
out-of-tree binutils -mquark-strip-lock patch was upstreamed as the 
-momit-lock-prefix option. The meta-intel layer included wic support 
making it dead-simple to create an SDcard from the build artifacts 
(yay!). Uclibc support died with Krogoth [2.1] (boo). And the 
suggested kernel for Quark moved from upstream linux-3.8 with about 
two dozen patches, to linux-intel-4.9 (as-is)... and this is where I'm 
stuck.


In the early days it doesn't seem like there was much distinction 
between Quark and Galileo, they were mostly synonymous. But by the 
time we get to Rocko, we find that the linux-intel kernel has support 
for Quark, but nothing for Galileo. When I boot the factory-installed 
Dylan image, I find loads of stuff under /sys/class/gpio, 
/sys/class/pwm, and /sys/class/platform which are what the Arduino 
code uses for identification and interaction with the Arduino headers. 
When I run linux-intel[*3] I have a /sys/class/gpio that only claims 8 
gpios are available for use, none of which appear to relate to the 
Arduino headers. Was the Galileo support never "upstreamed"? Not even 
in Intel's own kernel fork?
The linux-intel fork is essentially upstream + patches destined for 
upstream only. If the Galileo support never went upstream, it wouldn't 
make it into linux-intel, either.


With Rocko I can build a bootable image (yay!!) but without proper 
kernel support for Galileo the Arduino code stops quite abruptly when 
it finds it can't find /sys/class/platform/GalileoGen2. At this point 
I started looking at mraa/upm as a replacement for the Arduino 
libraries, but they have a similar problem. When trying to run the 
"blink_onboard.c" example program (the mraa equivalent to Arduino's 
Blink program) it fails because it wants to use GPIO13 and 31, but the 
kernel says there are only 8 GPIOs available.
I think the kernel offset these by 256 or something... Stephano can 
probably help here. I believe he got GPIO stuff working.


In summary:
- I can build a toolchain using Galileo-Runtime.git and Poky Dylan in 
a VM that I can install in place of the Arduino toolchain, but this 
doesn't gain me much since the default Arduino toolchain is based on 
these same layers/versions[*4]
- I can build, but can't assemble a working rootfs for my Galileo from 
Dylan
- I can't build a toolchain nor assemble a working rootfs from 
anything until I get to Rocko
- with Rocko I can build a bootable rootfs for my Galileo and a 
working toolchain for Arduino and/or I can use mraa/upm; however none 
of these programs work because although Rocko supports Quark (to some 
extent) support for Galileo seems to have stopped back in Dylan


Thank you for reading to the end. I'm curious to know if anyone would 
like to comment o

Re: [meta-intel] outdated dpdk-dev-libibverbs

[Cal Sullivan]

Hi Awais,

I don't know the history of why that version of libibverbs was used 
instead. Considering it no longer exists, I agree that it should be 
changed. Unfortunately I don't have any experience and likely lack the 
hardware for using dpdk, so I can only go as far as making sure it 
builds OK.


If you (or any other users of meta-intel-dpdk on the list) could test 
using upstream libibverbs it would be much appreciated. I could then fix 
it to use upstream libibverbs or take a patch for it.


Thanks,
Cal

On 03/09/2018 03:02 AM, Belal, Awais wrote:


Hi,


I was going through the meta-dpdk layer () and the actual dpdk package 
depends on dpdk-dev-libibverbs. Now, looking at the recipe for 
dpdk-dev-libibverbs it uses and outdated SRC_URI for fetching the 
sources (the actual tarball pointed to:  does not exist) and the yocto 
mirror is used to fetch the tarball instead. Are there any plans of 
fixing/updating this? Why isn't this using a generic libibverbs source?



BR,
/Awais/




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

Re: [meta-intel] [PATCH] systemd-boot: fix bbappend file to suit latest version

[Cal Sullivan]

Thanks for the patch. I assume this is needed when OE-core merges the 
update to v236?


Thanks,
Cal

On 03/04/2018 06:03 PM, Chen Qi wrote:

Fix the bbappend file to suit the latest systemd version.

As systemd has now dropped autotools support, using ninja
instead of make in do_compile.

Signed-off-by: Chen Qi 
---
  recipes-bsp/systemd-boot/systemd-boot_%.bbappend | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/systemd-boot/systemd-boot_%.bbappend 
b/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
index 9e6cc16..46dd8a4 100644
--- a/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
+++ b/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
@@ -7,11 +7,11 @@ SRC_URI_append_intel-x86-common = " \
  PACKAGE_ARCH_intel-x86-common = "${INTEL_COMMON_PACKAGE_ARCH}"
  
  do_compile_append_intel-x86-common() {

-   oe_runmake linux${SYSTEMD_BOOT_EFI_ARCH}.efi.stub
+   ninja src/boot/efi/linux${SYSTEMD_BOOT_EFI_ARCH}.efi.stub
  }
  
  do_deploy_append_intel-x86-common() {

-   install ${B}/linux*.efi.stub ${DEPLOYDIR}
+   install ${B}/src/boot/efi/linux*.efi.stub ${DEPLOYDIR}
  }
  
  # includes rmc-boot.inc if rmc-boot is the EFI_PROVIDER


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

Re: [meta-intel] [PATCH 2/2] conf: override WKS_FILE_DEPENDS for intel machines

[Cal Sullivan]

I've noticed a corner case in which this causes a failure.

If you set WKS_FILE = "mkefidisk.wks" manually, grub-efi does not get 
put in the boot partition. To make matters worse, wic does not report an 
error, its just silent.


Thanks,
Cal

On 02/13/2018 03:32 AM, Anuj Mittal wrote:

WKS_FILE_DEPENDS includes all the dependencies for producing wic images
and is meant to be overridden with correct set by image recipes. Right now,
the default values result in grub-efi being built even when EFI_PROVIDER
is set to systemd-boot.

Change the value to depend only on the EFI_PROVIDER bootloader.

Signed-off-by: Anuj Mittal 
---
  conf/machine/intel-core2-32.conf  | 1 +
  conf/machine/intel-corei7-64.conf | 1 +
  2 files changed, 2 insertions(+)

diff --git a/conf/machine/intel-core2-32.conf b/conf/machine/intel-core2-32.conf
index aa8a579..c48023c 100644
--- a/conf/machine/intel-core2-32.conf
+++ b/conf/machine/intel-core2-32.conf
@@ -32,3 +32,4 @@ APPEND += "rootwait console=ttyS0,115200 console=ttyPCH0,115200 
console=tty0"
  
  IMAGE_FSTYPES += "wic"

  WKS_FILE ?= "${@bb.utils.contains_any("EFI_PROVIDER", "systemd-boot rmc-boot", 
"systemd-bootdisk.wks", "mkefidisk.wks", d)}"
+WKS_FILE_DEPENDS ?= "${WKS_FILE_DEPENDS_DEFAULT} syslinux ${EFI_PROVIDER}"
diff --git a/conf/machine/intel-corei7-64.conf 
b/conf/machine/intel-corei7-64.conf
index 78c52ee..c4ce335 100644
--- a/conf/machine/intel-corei7-64.conf
+++ b/conf/machine/intel-corei7-64.conf
@@ -42,3 +42,4 @@ APPEND += "rootwait console=ttyS0,115200 console=tty0"
  
  IMAGE_FSTYPES += "wic"

  WKS_FILE ?= "${@bb.utils.contains_any("EFI_PROVIDER", "systemd-boot rmc-boot", 
"systemd-bootdisk.wks", "mkefidisk.wks", d)}"
+WKS_FILE_DEPENDS ?= "${WKS_FILE_DEPENDS_DEFAULT} syslinux ${EFI_PROVIDER}"


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

Re: [meta-intel] [PATCH v3] intel-vaapi-driver: upgrade to 2.0.0

[Cal Sullivan]

Yep that fixed it.

NOTE: recipe intel-vaapi-driver-2.0.0-r0: task do_configure: Succeeded 
Thanks, Cal


On 02/06/2018 02:55 PM, Cal Sullivan wrote:

I didn't. I'll try with those applied.

Thanks,
Cal

On 02/06/2018 02:13 PM, Burton, Ross wrote:

Did you also pick the oe-core updates? (not yet in master)

Ross

On 6 February 2018 at 21:43, Cal Sullivan 
<mailto:california.l.sulli...@intel.com>> wrote:


Getting a strange error when building for x32:

| checking for pkg-config...

/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x32/build/build/tmp/work/x86_64_x32-poky-linux-gnux32/intel-vaapi-driver/2.0.0-r0/recipe-sysroot-native/usr/bin/pkg-config
| configure: WARNING: using cross tools not prefixed with host
triplet | checking pkg-config is at least version 0.9.0... yes |
checking for libdrm >= 2.4.52... yes | checking for intel-gen4asm
>= 1.9... no | checking for intel-gen4asm... no | checking for
git...

/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x32/build/build/tmp/hosttools/git
| checking for libva >= 1.0.0... no | configure: error: Package
requirements (libva >= 1.0.0) were not met: | | Requested 'libva
>= 1.0.0' but version of libva is 0.40.0 | | Consider adjusting
the PKG_CONFIG_PATH environment variable if you | installed
software in a non-standard prefix. | | Alternatively, you may set
the environment variables LIBVA_DEPS_CFLAGS | and LIBVA_DEPS_LIBS
to avoid the need to call pkg-config. | See the pkg-config man
page for more details. Initially I was thinking that a host libva
was getting picked up, but libva 0.40 doesn't appear to exist.
Thanks, Cal

On 02/06/2018 12:38 AM, Anuj Mittal wrote:

Major changes:

* Bump version to 2.0.0
* Add support for Coffee Lake (aka. CFL)
   - Decoding: H.264/MPEG-2/VC-1/JPEG/VP8/HEVC/HEVC 10-bit/VP9/VP9 10-bit
   - Encoding: H.264/MPEG-2/JPEG/VP8/VP9/HEVC/HEVC 10-bit/AVC low power 
CQP/CBR/VBR mode
   - VPP: CSC/scaling/NoiseReduction/Deinterlacing{Bob, MotionAdaptive, 
MotionCompensated}/ColorBalance/STD
* Add support for H264 FEI
* Add support for HEVC ROI encoding
* Add support for intensity compensation for VC-1 decoding
* Improve the quality of the H264 encoder on BDW/BSW
* Improve the CSC performance between I420/NV12/P010/YUY2/VYUY format
* Improve the performace of va{Get, Put}Image for I420/NV12/P010/YUY2/VYUY 
format
* Fix image corruption for VP9 decoding
* Fix race condition in wayland support
* Fix ROI support in VDEnc support
* Fix corrupted stream when using VDEnc CBR/VBR
* Fix GCC 7.1.1 warnings/errors
* Update the shader for HEVC encoding

The upstream package name now is intel-vaapi-driver instead of 
libva-intel-driver.

Updated to point to release tarball instead of git. Also, changed
the URLs to point to new project page.

Signed-off-by: Anuj Mittal 
<mailto:anuj.mit...@intel.com>
---
  conf/include/maintainers.inc |  2 +-
  ...intel-driver_1.8.3.bb <http://intel-driver_1.8.3.bb>  
=>intel-vaapi-driver_2.0.0.bb <http://intel-vaapi-driver_2.0.0.bb>} | 16 
+++-
  recipes-multimedia/libva/va-intel.bb <http://va-intel.bb> 
 |  4 ++--
  3 files changed, 10 insertions(+), 12 deletions(-)
  rename recipes-multimedia/libva/{libva-intel-driver_1.8.3.bb 
<http://libva-intel-driver_1.8.3.bb>  =>intel-vaapi-driver_2.0.0.bb 
<http://intel-vaapi-driver_2.0.0.bb>} (62%)

diff --git a/conf/include/maintainers.inc b/conf/include/maintainers.inc
index 64896c3..0ab61ab 100644
--- a/conf/include/maintainers.inc
+++ b/conf/include/maintainers.inc
@@ -8,7 +8,7 @@ RECIPE_MAINTAINER_pn-intel-gpu-tools = "Anuj 
Mittal <mailto:anuj.mit...@intel.com>"
  RECIPE_MAINTAINER_pn-intel-microcode = "California 
Sullivan
<mailto:california.l.sulli...@intel.com>"
  RECIPE_MAINTAINER_pn-core-image-minimal-initramfs = "California 
Sullivan
<mailto:califorddnia.l.sulli...@intel.com>"
  RECIPE_MAINTAINER_pn-iucode-tool = "California 
Sullivan
<mailto:california.l.sulli...@intel.com>"
-RECIPE_MAINTAINER_pn-libva-intel-driver = "Anuj Mittal 
<mailto:anuj.mit...@intel.com>"
+RECIPE_MAINTAINER_pn-intel-vaapi-driver = "Anuj Mittal 
<mailto:anuj.mit...@intel.com>"
  RECIPE_MAINTAINER_pn-libyami = "Anuj Mittal 
<mailto:anuj.mit...@intel.com>"
  RECIPE_MAINTAINER_pn-libyami-utils = "Anuj Mittal 
<mailto:anuj.mit...@intel.com>"
  RECIPE_MAINTAINER_pn-linux-intel = "California 
Sullivan
<mailto:california.l.sulli...@intel.com>"
diff --git a/recipes-multimedia/libva/libva-intel-driver_1.8.3.bb 
<http://libva-intel-d

Re: [meta-intel] [PATCH v3] intel-vaapi-driver: upgrade to 2.0.0

[Cal Sullivan]

I didn't. I'll try with those applied.

Thanks,
Cal

On 02/06/2018 02:13 PM, Burton, Ross wrote:

Did you also pick the oe-core updates? (not yet in master)

Ross

On 6 February 2018 at 21:43, Cal Sullivan 
<mailto:california.l.sulli...@intel.com>> wrote:


Getting a strange error when building for x32:

| checking for pkg-config...

/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x32/build/build/tmp/work/x86_64_x32-poky-linux-gnux32/intel-vaapi-driver/2.0.0-r0/recipe-sysroot-native/usr/bin/pkg-config
| configure: WARNING: using cross tools not prefixed with host
triplet | checking pkg-config is at least version 0.9.0... yes |
checking for libdrm >= 2.4.52... yes | checking for intel-gen4asm
>= 1.9... no | checking for intel-gen4asm... no | checking for
git...

/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x32/build/build/tmp/hosttools/git
| checking for libva >= 1.0.0... no | configure: error: Package
requirements (libva >= 1.0.0) were not met: | | Requested 'libva
>= 1.0.0' but version of libva is 0.40.0 | | Consider adjusting
the PKG_CONFIG_PATH environment variable if you | installed
software in a non-standard prefix. | | Alternatively, you may set
the environment variables LIBVA_DEPS_CFLAGS | and LIBVA_DEPS_LIBS
to avoid the need to call pkg-config. | See the pkg-config man
page for more details. Initially I was thinking that a host libva
was getting picked up, but libva 0.40 doesn't appear to exist.
Thanks, Cal

On 02/06/2018 12:38 AM, Anuj Mittal wrote:

Major changes:

* Bump version to 2.0.0
* Add support for Coffee Lake (aka. CFL)
   - Decoding: H.264/MPEG-2/VC-1/JPEG/VP8/HEVC/HEVC 10-bit/VP9/VP9 10-bit
   - Encoding: H.264/MPEG-2/JPEG/VP8/VP9/HEVC/HEVC 10-bit/AVC low power 
CQP/CBR/VBR mode
   - VPP: CSC/scaling/NoiseReduction/Deinterlacing{Bob, MotionAdaptive, 
MotionCompensated}/ColorBalance/STD
* Add support for H264 FEI
* Add support for HEVC ROI encoding
* Add support for intensity compensation for VC-1 decoding
* Improve the quality of the H264 encoder on BDW/BSW
* Improve the CSC performance between I420/NV12/P010/YUY2/VYUY format
* Improve the performace of va{Get, Put}Image for I420/NV12/P010/YUY2/VYUY 
format
* Fix image corruption for VP9 decoding
* Fix race condition in wayland support
* Fix ROI support in VDEnc support
* Fix corrupted stream when using VDEnc CBR/VBR
* Fix GCC 7.1.1 warnings/errors
* Update the shader for HEVC encoding

The upstream package name now is intel-vaapi-driver instead of 
libva-intel-driver.

Updated to point to release tarball instead of git. Also, changed
the URLs to point to new project page.

Signed-off-by: Anuj Mittal 
<mailto:anuj.mit...@intel.com>
---
  conf/include/maintainers.inc |  2 +-
  ...intel-driver_1.8.3.bb <http://intel-driver_1.8.3.bb>  
=>intel-vaapi-driver_2.0.0.bb <http://intel-vaapi-driver_2.0.0.bb>} | 16 
+++-
  recipes-multimedia/libva/va-intel.bb <http://va-intel.bb> 
 |  4 ++--
  3 files changed, 10 insertions(+), 12 deletions(-)
  rename recipes-multimedia/libva/{libva-intel-driver_1.8.3.bb 
<http://libva-intel-driver_1.8.3.bb>  =>intel-vaapi-driver_2.0.0.bb 
<http://intel-vaapi-driver_2.0.0.bb>} (62%)

diff --git a/conf/include/maintainers.inc b/conf/include/maintainers.inc
index 64896c3..0ab61ab 100644
--- a/conf/include/maintainers.inc
+++ b/conf/include/maintainers.inc
@@ -8,7 +8,7 @@ RECIPE_MAINTAINER_pn-intel-gpu-tools = "Anuj 
Mittal <mailto:anuj.mit...@intel.com>"
  RECIPE_MAINTAINER_pn-intel-microcode = "California 
Sullivan
<mailto:california.l.sulli...@intel.com>"
  RECIPE_MAINTAINER_pn-core-image-minimal-initramfs = "California 
Sullivan
<mailto:califorddnia.l.sulli...@intel.com>"
  RECIPE_MAINTAINER_pn-iucode-tool = "California 
Sullivan
<mailto:california.l.sulli...@intel.com>"
-RECIPE_MAINTAINER_pn-libva-intel-driver = "Anuj Mittal 
<mailto:anuj.mit...@intel.com>"
+RECIPE_MAINTAINER_pn-intel-vaapi-driver = "Anuj Mittal 
<mailto:anuj.mit...@intel.com>"
  RECIPE_MAINTAINER_pn-libyami = "Anuj Mittal 
<mailto:anuj.mit...@intel.com>"
  RECIPE_MAINTAINER_pn-libyami-utils = "Anuj Mittal 
<mailto:anuj.mit...@intel.com>"
  RECIPE_MAINTAINER_pn-linux-intel = "California 
Sullivan
<mailto:california.l.sulli...@intel.com>"
diff --git a/recipes-multimedia/libva/libva-intel-driver_1.8.3.bb 
<http://libva-intel-driver_1.8.3.bb>  
b/recipes-multimedia/libva/intel-vaapi-driver_2.0.0.bb 
<http://intel-vaapi-driver_2.0.0.bb>
similarity index 62

Re: [meta-intel] [PATCH v3] intel-vaapi-driver: upgrade to 2.0.0

[Cal Sullivan]

Getting a strange error when building for x32:

| checking for pkg-config... 
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x32/build/build/tmp/work/x86_64_x32-poky-linux-gnux32/intel-vaapi-driver/2.0.0-r0/recipe-sysroot-native/usr/bin/pkg-config 
| configure: WARNING: using cross tools not prefixed with host triplet | 
checking pkg-config is at least version 0.9.0... yes | checking for 
libdrm >= 2.4.52... yes | checking for intel-gen4asm >= 1.9... no | 
checking for intel-gen4asm... no | checking for git... 
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x32/build/build/tmp/hosttools/git 
| checking for libva >= 1.0.0... no | configure: error: Package 
requirements (libva >= 1.0.0) were not met: | | Requested 'libva >= 
1.0.0' but version of libva is 0.40.0 | | Consider adjusting the 
PKG_CONFIG_PATH environment variable if you | installed software in a 
non-standard prefix. | | Alternatively, you may set the environment 
variables LIBVA_DEPS_CFLAGS | and LIBVA_DEPS_LIBS to avoid the need to 
call pkg-config. | See the pkg-config man page for more details. 
Initially I was thinking that a host libva was getting picked up, but 
libva 0.40 doesn't appear to exist. Thanks, Cal


On 02/06/2018 12:38 AM, Anuj Mittal wrote:

Major changes:

* Bump version to 2.0.0
* Add support for Coffee Lake (aka. CFL)
   - Decoding: H.264/MPEG-2/VC-1/JPEG/VP8/HEVC/HEVC 10-bit/VP9/VP9 10-bit
   - Encoding: H.264/MPEG-2/JPEG/VP8/VP9/HEVC/HEVC 10-bit/AVC low power 
CQP/CBR/VBR mode
   - VPP: CSC/scaling/NoiseReduction/Deinterlacing{Bob, MotionAdaptive, 
MotionCompensated}/ColorBalance/STD
* Add support for H264 FEI
* Add support for HEVC ROI encoding
* Add support for intensity compensation for VC-1 decoding
* Improve the quality of the H264 encoder on BDW/BSW
* Improve the CSC performance between I420/NV12/P010/YUY2/VYUY format
* Improve the performace of va{Get, Put}Image for I420/NV12/P010/YUY2/VYUY 
format
* Fix image corruption for VP9 decoding
* Fix race condition in wayland support
* Fix ROI support in VDEnc support
* Fix corrupted stream when using VDEnc CBR/VBR
* Fix GCC 7.1.1 warnings/errors
* Update the shader for HEVC encoding

The upstream package name now is intel-vaapi-driver instead of 
libva-intel-driver.

Updated to point to release tarball instead of git. Also, changed
the URLs to point to new project page.

Signed-off-by: Anuj Mittal 
---
  conf/include/maintainers.inc |  2 +-
  ...intel-driver_1.8.3.bb => intel-vaapi-driver_2.0.0.bb} | 16 +++-
  recipes-multimedia/libva/va-intel.bb |  4 ++--
  3 files changed, 10 insertions(+), 12 deletions(-)
  rename recipes-multimedia/libva/{libva-intel-driver_1.8.3.bb => 
intel-vaapi-driver_2.0.0.bb} (62%)

diff --git a/conf/include/maintainers.inc b/conf/include/maintainers.inc
index 64896c3..0ab61ab 100644
--- a/conf/include/maintainers.inc
+++ b/conf/include/maintainers.inc
@@ -8,7 +8,7 @@ RECIPE_MAINTAINER_pn-intel-gpu-tools = "Anuj Mittal 
"
  RECIPE_MAINTAINER_pn-intel-microcode = "California Sullivan 
"
  RECIPE_MAINTAINER_pn-core-image-minimal-initramfs = "California Sullivan 
"
  RECIPE_MAINTAINER_pn-iucode-tool = "California Sullivan 
"
-RECIPE_MAINTAINER_pn-libva-intel-driver = "Anuj Mittal "
+RECIPE_MAINTAINER_pn-intel-vaapi-driver = "Anuj Mittal "
  RECIPE_MAINTAINER_pn-libyami = "Anuj Mittal "
  RECIPE_MAINTAINER_pn-libyami-utils = "Anuj Mittal "
  RECIPE_MAINTAINER_pn-linux-intel = "California Sullivan 
"
diff --git a/recipes-multimedia/libva/libva-intel-driver_1.8.3.bb 
b/recipes-multimedia/libva/intel-vaapi-driver_2.0.0.bb
similarity index 62%
rename from recipes-multimedia/libva/libva-intel-driver_1.8.3.bb
rename to recipes-multimedia/libva/intel-vaapi-driver_2.0.0.bb
index 72451c0..e651107 100644
--- a/recipes-multimedia/libva/libva-intel-driver_1.8.3.bb
+++ b/recipes-multimedia/libva/intel-vaapi-driver_2.0.0.bb
@@ -1,10 +1,10 @@
  SUMMARY = "VA driver for Intel G45 & HD Graphics family"
-DESCRIPTION = "libva-driver-intel is the VA-API implementation \
+DESCRIPTION = "intel-vaapi-driver is the VA-API implementation \
  for Intel G45 chipsets and Intel HD Graphics for Intel Core \
  processor family."
  
-HOMEPAGE = "http://www.freedesktop.org/wiki/Software/vaapi";

-BUGTRACKER = "https://bugs.freedesktop.org";
+HOMEPAGE = "https://github.com/intel/intel-vaapi-driver";
+BUGTRACKER = "https://github.com/intel/intel-vaapi-driver/issues";
  
  LICENSE = "MIT"

  LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
@@ -13,11 +13,11 @@ COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
  
  DEPENDS = "libva libdrm"
  
-SRC_URI = "git://github.com/01org/intel-vaapi-driver.git;branch=v1.8-branch"

-# 1.8.3 release tag
-SRCREV = "f1d9ceddc0e84ed8d44dd59017b0e19b75dd5dcd"
+SRC_URI = 
"https://github.com/intel/${BPN}/releases/download/${PV}/${BPN}-${PV}.tar.bz2";
+SRC_URI[md5sum] = "1288657b572b563b24ca27c60a10a032"
+SRC_URI[sha256sum] = 
"10f6b0a91f34715d8d4d9a9e0fb3cc0afe

Re: [meta-intel] menuconfig not working with rocko branch and linux-intel

[Cal Sullivan]

On 01/24/2018 07:54 AM, Max Halldén wrote:

Sure, but it's really not much. I can reproduce it with poky
and meta-intel at rocko branch with almost no change to the
default configuration.

If I diff meta-poky/conf/local.conf.sample to my local.conf I get:
38c38
< MACHINE ??= "qemux86"
---
> MACHINE = "intel-corei7-64"

and same for meta-poky/conf/bblayers.conf.sample and my bblayers.conf:
<   ##OEROOT##/meta \
<   ##OEROOT##/meta-poky \
<   ##OEROOT##/meta-yocto-bsp \
---
>   /home/max/projects/menuconfigtest/poky/meta \
>   /home/max/projects/menuconfigtest/poky/meta-poky \
>   /home/max/projects/menuconfigtest/poky/meta-yocto-bsp \
>   /home/max/projects/menuconfigtest/poky/meta-intel \

Originally I built with the crops/poky:ubuntu-16.04 docker
image, but I can also reproduce it natively on my Ubuntu
17.10 machine.

But I think I found a workaround at least. Installing
libncurses5-dev on the build host solves the problem so
that's probably why you can't reproduce it.


Yep, that was it. After removing ncurses-devel from my system I can 
reproduce it.


I figured out why it works for linux-yocto and not linux-intel as well. 
It looks like linux-yocto carries a patch that allows you to override 
the ncurses library and headers to not use the host's. See commit 
"e6ebc8e654 menuconfig,check-lxdiaglog.sh: Allow specification of 
ncurses location" in linux-yocto-4.12.


+Bruce, Jason

I see that it was attempted to upstream this patch, but that it never 
made it. Do either of you remember the response that it got?


Thanks,
Cal



Still, libncurses5-dev is not needed when setting
MACHINE='qemux86' instead of intel-corei7-64, which seems
weird.

Thanks,
Max


On 2018-01-23 20:48, Cal Sullivan wrote:
I wasn't able to reproduce this with either the HEAD of rocko 
branches or their release tags.

Could you share any changes in your local.conf and your bblayers.conf?

Thanks,
Cal

On 01/22/2018 01:51 AM, Max Halldén wrote:

Hi all,

I have a project based on poky and the meta-intel layer and
both are on the rocko (2.4) branch.

I have a problem with menuconfig not working. Specifically
'bitbake -c menuconfig virtual/kernel' works when using
'vanilla' poky, but not after adding the meta-intel layer
and setting 'MACHINE=intel-corei7-64'.

I've added some of the error I get below, which seems to
indicate ncurses is missing, but I can't understand what it
is with the meta-intel configuration that makes it not work
for linux-intel when it's working with linux-yocto.

I've looked for anything ncurses in linux-yocto that isn't
in linux-intel, but can't find anything that looks wrong.

Best regards
Max

[...]
menubox.c:(.text+0x874): undefined reference to `wrefresh'
menubox.c:(.text+0x890): undefined reference to `wgetch'
menubox.c:(.text+0x99a): undefined reference to `delwin'
menubox.c:(.text+0x9a2): undefined reference to `delwin'
menubox.c:(.text+0xac2): undefined reference to `wnoutrefresh'
menubox.c:(.text+0xacb): undefined reference to `wrefresh'
menubox.c:(.text+0xb18): undefined reference to `delwin'
menubox.c:(.text+0xb20): undefined reference to `delwin'
menubox.c:(.text+0xb27): undefined reference to `stdscr'
menubox.c:(.text+0xc25): undefined reference to `delwin'
menubox.c:(.text+0xc2d): undefined reference to `delwin'
menubox.c:(.text+0xcdf): undefined reference to `wrefresh'
menubox.c:(.text+0xdf8): undefined reference to `stdscr'
menubox.c:(.text+0xfb9): undefined reference to `wbkgdset'
menubox.c:(.text+0xfc0): undefined reference to `acs_map'
menubox.c:(.text+0xfc7): undefined reference to `waddch'
menubox.c:(.text+0x1059): undefined reference to `scrollok'
scripts/kconfig/lxdialog/menubox.o: In function `do_scroll':
menubox.c:(.text+0x38): undefined reference to `wrefresh'
scripts/kconfig/lxdialog/menubox.o: In function `do_print_item':
menubox.c:(.text+0x17e): undefined reference to `wrefresh'
scripts/kconfig/lxdialog/menubox.o: In function `print_buttons':
menubox.c:(.text+0x2b8): undefined reference to `wrefresh'
scripts/kconfig/lxdialog/menubox.o: In function 
`print_arrows.constprop.0':

menubox.c:(.text+0x3c3): undefined reference to `wrefresh'
collect2: error: ld returned 1 exit status
scripts/Makefile.host:116: recipe for target 'scripts/kconfig/mconf' 
failed

make[3]: *** [scripts/kconfig/mconf] Error 1
/workdir/build/workspace/sources/linux-intel/Makefile:546: recipe 
for target 'menuconfig' failed

make[2]: *** [menuconfig] Error 2
Makefile:150: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
Makefile:24: recipe for target '__sub-make' failed
make: *** [__sub-make] Error 2
Command failed.








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

Re: [meta-intel] menuconfig not working with rocko branch and linux-intel

[Cal Sullivan]

I wasn't able to reproduce this with either the HEAD of rocko branches 
or their release tags.

Could you share any changes in your local.conf and your bblayers.conf?

Thanks,
Cal

On 01/22/2018 01:51 AM, Max Halldén wrote:

Hi all,

I have a project based on poky and the meta-intel layer and
both are on the rocko (2.4) branch.

I have a problem with menuconfig not working. Specifically
'bitbake -c menuconfig virtual/kernel' works when using
'vanilla' poky, but not after adding the meta-intel layer
and setting 'MACHINE=intel-corei7-64'.

I've added some of the error I get below, which seems to
indicate ncurses is missing, but I can't understand what it
is with the meta-intel configuration that makes it not work
for linux-intel when it's working with linux-yocto.

I've looked for anything ncurses in linux-yocto that isn't
in linux-intel, but can't find anything that looks wrong.

Best regards
Max

[...]
menubox.c:(.text+0x874): undefined reference to `wrefresh'
menubox.c:(.text+0x890): undefined reference to `wgetch'
menubox.c:(.text+0x99a): undefined reference to `delwin'
menubox.c:(.text+0x9a2): undefined reference to `delwin'
menubox.c:(.text+0xac2): undefined reference to `wnoutrefresh'
menubox.c:(.text+0xacb): undefined reference to `wrefresh'
menubox.c:(.text+0xb18): undefined reference to `delwin'
menubox.c:(.text+0xb20): undefined reference to `delwin'
menubox.c:(.text+0xb27): undefined reference to `stdscr'
menubox.c:(.text+0xc25): undefined reference to `delwin'
menubox.c:(.text+0xc2d): undefined reference to `delwin'
menubox.c:(.text+0xcdf): undefined reference to `wrefresh'
menubox.c:(.text+0xdf8): undefined reference to `stdscr'
menubox.c:(.text+0xfb9): undefined reference to `wbkgdset'
menubox.c:(.text+0xfc0): undefined reference to `acs_map'
menubox.c:(.text+0xfc7): undefined reference to `waddch'
menubox.c:(.text+0x1059): undefined reference to `scrollok'
scripts/kconfig/lxdialog/menubox.o: In function `do_scroll':
menubox.c:(.text+0x38): undefined reference to `wrefresh'
scripts/kconfig/lxdialog/menubox.o: In function `do_print_item':
menubox.c:(.text+0x17e): undefined reference to `wrefresh'
scripts/kconfig/lxdialog/menubox.o: In function `print_buttons':
menubox.c:(.text+0x2b8): undefined reference to `wrefresh'
scripts/kconfig/lxdialog/menubox.o: In function 
`print_arrows.constprop.0':

menubox.c:(.text+0x3c3): undefined reference to `wrefresh'
collect2: error: ld returned 1 exit status
scripts/Makefile.host:116: recipe for target 'scripts/kconfig/mconf' 
failed

make[3]: *** [scripts/kconfig/mconf] Error 1
/workdir/build/workspace/sources/linux-intel/Makefile:546: recipe for 
target 'menuconfig' failed

make[2]: *** [menuconfig] Error 2
Makefile:150: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
Makefile:24: recipe for target '__sub-make' failed
make: *** [__sub-make] Error 2
Command failed.




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

Re: [meta-intel] [PATCH] dpdk: Add dpdk-test to include test programs

[Cal Sullivan]

On 01/02/2018 01:32 AM, He Zhe wrote:


On 2018年01月02日 16:59, Mittal, Anuj wrote:

Hi He Zhe,


  do_install () {
@@ -113,9 +118,20 @@ do_install () {
install -m 755 ${appname}
${D}/${INSTALL_PATH}/examples/`basename ${dirname}`/
done
done
+
+   # Install test
+   for dirname in ${S}/test/app/*
+   do
+   install -m 0755 -d ${D}/${INSTALL_PATH}/test
+
+   for appname in `find ${dirname} -regex 
".*test\/app\/[-0-9a-zA-Z0-
9/_]*$"`
+   do
+   install -m 755 ${appname} ${D}/${INSTALL_PATH}/test
+   done
+   done
  }

Does the dpdk makefile provide any way to install these at directly to $D? It 
looks like the install target installs these to RTE_OUTPUT. Does that need to 
be ${S}/RTE_TARGET?

After looking around the make files, there seems not. Like target "examples", 
we need to copy by ourselves.

Merged.

Thanks,
Cal



Thanks,
Zhe


Thanks,
Anuj



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

Re: [meta-intel] [PATCH 1/3] dpdk-dev-libibverbs: fix do_fetch failure in case of multilib

[Cal Sullivan]

On 01/05/2018 12:20 PM, Mark Asselstine wrote:

On Friday, January 5, 2018 3:17:27 PM EST Cal Sullivan wrote:

This sounds like the right way to go to me.

In the interim, should I take these patches in order to unblock the
conflict and the multilib issue?

Yes, this would help.

Mark


Merged.

Thanks,
Cal




Thanks,
Cal

On 01/04/2018 07:24 AM, Mark Asselstine wrote:

On Wednesday, January 3, 2018 2:02:31 PM EST Cal Sullivan wrote:

In actually testing this patch, I noticed that I was getting a fetcher
warning. After a little investigation I found that
https://github.com/Mellanox/dpdk-dev-libibverbs no longer exists and
we're only getting this thanks to the YP mirroring. Do you know of any
other location we could point to?

Maybe we should actually take this as a signal to revisit things. I am
having to piece things together as some of the history is lost with the
removal of the dpdk-dev-libibverbs repo and newer revisions of Mellanox
DPDK pages but I think we have enough to go on to move forward.

Looking at the history it appears as though dpdk-dev-libibverbs was and
"optimized" version of libibverbs for the ConnectX-3 (reference: https://
community.mellanox.com/docs/DOC-2197). The fact that Mellanox has dropped
the repository and now simply references libibverbs (and not
dpdk-dev-libibverbs) in its latest revision of the Mellanox DPDK
documentation (reference: https:// community.mellanox.com/docs/DOC-1502).
Leads me to believe that we should move on to simply use the latest
release of libibverbs.

So I really think the best solution is to drop dpdk-dev-libibverbs and
simply use libibverbs. This would drop the need to do any of the
'virtual/' do jiggery. We can host the libibverbs recipe here still or
move to oe-core, Bruce can use PREFERRED_VERSION to continue to use the
required version in meta-cloud-services...

Sorry about taking my time in coming to this conclusion. I was short on
time and flush with work before the holiday so didn't dig in enough to
make the right call.

MarkA


Thanks,
Cal

On 01/02/2018 05:27 PM, Chen Qi wrote:

Fix to correctly set SRC_URI and S to avoid do_fetch failure in case of
multilib.

Signed-off-by: Chen Qi 
---

.../dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.0.0.bb  | 8
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git
a/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0
.
0.0.bb
b/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0
.
0.0.bb index e40c63b..9118494 100644
---
a/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0
.
0.0.bb +++
b/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0
.
0.0.bb @@ -3,7 +3,7 @@ HOMEPAGE =
"https://github.com/Mellanox/dpdk-dev-libibverbs";>

LICENSE = "GPLv2"
LIC_FILES_CHKSUM =
"file://COPYING;md5=7c557f27dd795ba77cc419dddc656b51"

-SRC_URI =
"https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${PV
}
.tar.gz;name=${PN} \ +SRC_URI =
"https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${PV
}
.tar.gz \>

   file://init_c.patch \
   file://0001-Fix-build-with-clang.patch \
   file://0002-typecast-enum-to-int-before-comparison.patch \

@@ -11,8 +11,8 @@ SRC_URI =
"https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${>

   file://0004-Fix-clang-warnings.patch \
   "

-SRC_URI[dpdk-dev-libibverbs.md5sum] =
"65234ee278eb437a7069326f37cd4d86"
-SRC_URI[dpdk-dev-libibverbs.sha256sum] =
"a6471515556cb8d10ad471bb7efb8cf760b248a28aceb57d4534d50d572f56cd"
+SRC_URI[md5sum] = "65234ee278eb437a7069326f37cd4d86"
+SRC_URI[sha256sum] =
"a6471515556cb8d10ad471bb7efb8cf760b248a28aceb57d4534d50d572f56cd">

# A machine needs to enable this using:
# COMPATIBLE_MACHINE_pn-dpdk-dev-libibverbs = ""

@@ -20,7 +20,7 @@ SRC_URI[dpdk-dev-libibverbs.sha256sum] =
"a6471515556cb8d10ad471bb7efb8cf760b248>

COMPATIBLE_MACHINE = "null"
COMPATIBLE_HOST_libc-musl_class-target = "null"

-S = "${WORKDIR}/${PN}-libibverbs-${PV}"
+S = "${WORKDIR}/dpdk-dev-libibverbs-libibverbs-${PV}"

COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
DEPENDS = "libnl"




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

Re: [meta-intel] [PATCH 1/3] dpdk-dev-libibverbs: fix do_fetch failure in case of multilib

[Cal Sullivan]

This sounds like the right way to go to me.

In the interim, should I take these patches in order to unblock the 
conflict and the multilib issue?


Thanks,
Cal

On 01/04/2018 07:24 AM, Mark Asselstine wrote:

On Wednesday, January 3, 2018 2:02:31 PM EST Cal Sullivan wrote:

In actually testing this patch, I noticed that I was getting a fetcher
warning. After a little investigation I found that
https://github.com/Mellanox/dpdk-dev-libibverbs no longer exists and
we're only getting this thanks to the YP mirroring. Do you know of any
other location we could point to?

Maybe we should actually take this as a signal to revisit things. I am having
to piece things together as some of the history is lost with the removal of
the dpdk-dev-libibverbs repo and newer revisions of Mellanox DPDK pages but I
think we have enough to go on to move forward.

Looking at the history it appears as though dpdk-dev-libibverbs was and
"optimized" version of libibverbs for the ConnectX-3 (reference: https://
community.mellanox.com/docs/DOC-2197). The fact that Mellanox has dropped the
repository and now simply references libibverbs (and not dpdk-dev-libibverbs)
in its latest revision of the Mellanox DPDK documentation (reference: https://
community.mellanox.com/docs/DOC-1502). Leads me to believe that we should move
on to simply use the latest release of libibverbs.

So I really think the best solution is to drop dpdk-dev-libibverbs and simply
use libibverbs. This would drop the need to do any of the 'virtual/' do
jiggery. We can host the libibverbs recipe here still or move to oe-core,
Bruce can use PREFERRED_VERSION to continue to use the required version in
meta-cloud-services...

Sorry about taking my time in coming to this conclusion. I was short on time
and flush with work before the holiday so didn't dig in enough to make the
right call.

MarkA


Thanks,
Cal

On 01/02/2018 05:27 PM, Chen Qi wrote:

Fix to correctly set SRC_URI and S to avoid do_fetch failure in case of
multilib.

Signed-off-by: Chen Qi 
---

   .../dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.0.0.bb  | 8
    1 file changed, 4 insertions(+), 4 deletions(-)

diff --git
a/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.
0.0.bb
b/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.
0.0.bb index e40c63b..9118494 100644
---
a/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.
0.0.bb +++
b/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.
0.0.bb @@ -3,7 +3,7 @@ HOMEPAGE =
"https://github.com/Mellanox/dpdk-dev-libibverbs";>
   LICENSE = "GPLv2"
   LIC_FILES_CHKSUM =
   "file://COPYING;md5=7c557f27dd795ba77cc419dddc656b51"

-SRC_URI =
"https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${PV}
.tar.gz;name=${PN} \ +SRC_URI =
"https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${PV}
.tar.gz \>
  file://init_c.patch \
  file://0001-Fix-build-with-clang.patch \
  file://0002-typecast-enum-to-int-before-comparison.patch \

@@ -11,8 +11,8 @@ SRC_URI =
"https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${>
  file://0004-Fix-clang-warnings.patch \
  "

-SRC_URI[dpdk-dev-libibverbs.md5sum] = "65234ee278eb437a7069326f37cd4d86"
-SRC_URI[dpdk-dev-libibverbs.sha256sum] =
"a6471515556cb8d10ad471bb7efb8cf760b248a28aceb57d4534d50d572f56cd"
+SRC_URI[md5sum] = "65234ee278eb437a7069326f37cd4d86"
+SRC_URI[sha256sum] =
"a6471515556cb8d10ad471bb7efb8cf760b248a28aceb57d4534d50d572f56cd">
   # A machine needs to enable this using:
   # COMPATIBLE_MACHINE_pn-dpdk-dev-libibverbs = ""

@@ -20,7 +20,7 @@ SRC_URI[dpdk-dev-libibverbs.sha256sum] =
"a6471515556cb8d10ad471bb7efb8cf760b248>
   COMPATIBLE_MACHINE = "null"
   COMPATIBLE_HOST_libc-musl_class-target = "null"

-S = "${WORKDIR}/${PN}-libibverbs-${PV}"
+S = "${WORKDIR}/dpdk-dev-libibverbs-libibverbs-${PV}"

   COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
   DEPENDS = "libnl"




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

Re: [meta-intel] [PATCH 1/3] dpdk-dev-libibverbs: fix do_fetch failure in case of multilib

[Cal Sullivan]

In actually testing this patch, I noticed that I was getting a fetcher 
warning. After a little investigation I found that 
https://github.com/Mellanox/dpdk-dev-libibverbs no longer exists and 
we're only getting this thanks to the YP mirroring. Do you know of any 
other location we could point to?


Thanks,
Cal

On 01/02/2018 05:27 PM, Chen Qi wrote:

Fix to correctly set SRC_URI and S to avoid do_fetch failure in case of 
multilib.

Signed-off-by: Chen Qi 
---
  .../dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.0.0.bb  | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.0.0.bb 
b/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.0.0.bb
index e40c63b..9118494 100644
--- 
a/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.0.0.bb
+++ 
b/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.0.0.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "https://github.com/Mellanox/dpdk-dev-libibverbs";
  LICENSE = "GPLv2"
  LIC_FILES_CHKSUM =  "file://COPYING;md5=7c557f27dd795ba77cc419dddc656b51"
  
-SRC_URI = "https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${PV}.tar.gz;name=${PN} \

+SRC_URI = 
"https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${PV}.tar.gz
 \
 file://init_c.patch \
 file://0001-Fix-build-with-clang.patch \
 file://0002-typecast-enum-to-int-before-comparison.patch \
@@ -11,8 +11,8 @@ SRC_URI = 
"https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${
 file://0004-Fix-clang-warnings.patch \
 "
  
-SRC_URI[dpdk-dev-libibverbs.md5sum] = "65234ee278eb437a7069326f37cd4d86"

-SRC_URI[dpdk-dev-libibverbs.sha256sum] = 
"a6471515556cb8d10ad471bb7efb8cf760b248a28aceb57d4534d50d572f56cd"
+SRC_URI[md5sum] = "65234ee278eb437a7069326f37cd4d86"
+SRC_URI[sha256sum] = 
"a6471515556cb8d10ad471bb7efb8cf760b248a28aceb57d4534d50d572f56cd"
  
  # A machine needs to enable this using:

  # COMPATIBLE_MACHINE_pn-dpdk-dev-libibverbs = ""
@@ -20,7 +20,7 @@ SRC_URI[dpdk-dev-libibverbs.sha256sum] = 
"a6471515556cb8d10ad471bb7efb8cf760b248
  COMPATIBLE_MACHINE = "null"
  COMPATIBLE_HOST_libc-musl_class-target = "null"
  
-S = "${WORKDIR}/${PN}-libibverbs-${PV}"

+S = "${WORKDIR}/dpdk-dev-libibverbs-libibverbs-${PV}"
  COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
  DEPENDS = "libnl"
  


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

Re: [meta-intel] [PATCH 1/3] dpdk-dev-libibverbs: fix do_fetch failure in case of multilib

[Cal Sullivan]

These look good to me. I take it these take precedence over Mark's patch 
from before the break?


Thanks,
Cal

On 01/02/2018 05:27 PM, Chen Qi wrote:

Fix to correctly set SRC_URI and S to avoid do_fetch failure in case of 
multilib.

Signed-off-by: Chen Qi 
---
  .../dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.0.0.bb  | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.0.0.bb 
b/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.0.0.bb
index e40c63b..9118494 100644
--- 
a/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.0.0.bb
+++ 
b/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.0.0.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "https://github.com/Mellanox/dpdk-dev-libibverbs";
  LICENSE = "GPLv2"
  LIC_FILES_CHKSUM =  "file://COPYING;md5=7c557f27dd795ba77cc419dddc656b51"
  
-SRC_URI = "https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${PV}.tar.gz;name=${PN} \

+SRC_URI = 
"https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${PV}.tar.gz
 \
 file://init_c.patch \
 file://0001-Fix-build-with-clang.patch \
 file://0002-typecast-enum-to-int-before-comparison.patch \
@@ -11,8 +11,8 @@ SRC_URI = 
"https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${
 file://0004-Fix-clang-warnings.patch \
 "
  
-SRC_URI[dpdk-dev-libibverbs.md5sum] = "65234ee278eb437a7069326f37cd4d86"

-SRC_URI[dpdk-dev-libibverbs.sha256sum] = 
"a6471515556cb8d10ad471bb7efb8cf760b248a28aceb57d4534d50d572f56cd"
+SRC_URI[md5sum] = "65234ee278eb437a7069326f37cd4d86"
+SRC_URI[sha256sum] = 
"a6471515556cb8d10ad471bb7efb8cf760b248a28aceb57d4534d50d572f56cd"
  
  # A machine needs to enable this using:

  # COMPATIBLE_MACHINE_pn-dpdk-dev-libibverbs = ""
@@ -20,7 +20,7 @@ SRC_URI[dpdk-dev-libibverbs.sha256sum] = 
"a6471515556cb8d10ad471bb7efb8cf760b248
  COMPATIBLE_MACHINE = "null"
  COMPATIBLE_HOST_libc-musl_class-target = "null"
  
-S = "${WORKDIR}/${PN}-libibverbs-${PV}"

+S = "${WORKDIR}/dpdk-dev-libibverbs-libibverbs-${PV}"
  COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
  DEPENDS = "libnl"
  


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

Re: [meta-intel] opensslfoundation.com seems to have been down for while.

[Cal Sullivan]

It looks like meta-evo4k's medx-buildhistory.bbclass is invoked during 
parsing, catching this issue.


For now keep your local fix, and I'll talk to people internally that 
know more about qat about the right way to resolve this.


Thanks,
Cal

On 12/12/2017 01:06 PM, Paul Knopf wrote:
There is no SRCREV set, so during parse, bitbake queries to see if 
there is any new sources for the branch.


The moment I changed it to GitHub, it worked.

Here is the log. 
https://gist.github.com/pauldotknopf/b551cd42b7987f5eec01a85cb84c7d78


I am on pyro.

On Tue, Dec 12, 2017 at 3:27 PM, Cal Sullivan 
<mailto:california.l.sulli...@intel.com>> wrote:


Hmm, I wouldn't expect it to cause an error while parsing. What
release are you working with?

Also, any idea on how long that site has been down? If its been
down for a long time without anyone realizing it, could we just
remove the recipe?

Thanks,
Cal

On 12/12/2017 08:18 AM, Paul Knopf wrote:

The issue is with openssl-qat. I am not directly using it, but
opensslfoundation.com <http://opensslfoundation.com> gets ping'd
when parsing the recipes.

I have to patch the recipe until opensslfoundation.com
<http://opensslfoundation.com> comes back online.

As anyone else experiencing this?

Here is the patch I have applied to my local machine.

diff --git
a/common/recipes-extended/openssl-qat/openssl-qat_0.4.9-009.bb
<http://openssl-qat_0.4.9-009.bb>
b/common/recipes-extended/openssl-qat/openssl-qat_0.4.9-009.bb
<http://openssl-qat_0.4.9-009.bb>
index e3d8ccc..31d8a8f 100644
---
a/common/recipes-extended/openssl-qat/openssl-qat_0.4.9-009.bb
<http://openssl-qat_0.4.9-009.bb>
+++
b/common/recipes-extended/openssl-qat/openssl-qat_0.4.9-009.bb
<http://openssl-qat_0.4.9-009.bb>
@@ -2,7 +2,7 @@ include openssl-qat.inc

 OPENSSL_VERSION = "1.0.1async"

-SRC_URI  +=

"git://opensslfoundation.com/openssl-async.git;branch=OpenSSL_1_0_1-async;rev=asynch_v0.4.9-009

<http://opensslfoundation.com/openssl-async.git;branch=OpenSSL_1_0_1-async;rev=asynch_v0.4.9-009>
\
+SRC_URI  +=

"git://github.com/RIFTIO/openssl-async.git;branch=OpenSSL_1_0_1-async;rev=asynch_v0.4.9-009

<http://github.com/RIFTIO/openssl-async.git;branch=OpenSSL_1_0_1-async;rev=asynch_v0.4.9-009>
\
file://openssl-qat_0.4.9-009-openssl_qat-add-version-script.patch \

file://openssl-qat_0.4.9-009-openssl_qat-add-openssl-async-specific-symbols.patch
\
              "







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

Re: [meta-intel] opensslfoundation.com seems to have been down for while.

[Cal Sullivan]

Hmm, I wouldn't expect it to cause an error while parsing. What release 
are you working with?


Also, any idea on how long that site has been down? If its been down for 
a long time without anyone realizing it, could we just remove the recipe?


Thanks,
Cal

On 12/12/2017 08:18 AM, Paul Knopf wrote:
The issue is with openssl-qat. I am not directly using it, but 
opensslfoundation.com  gets ping'd when 
parsing the recipes.


I have to patch the recipe until opensslfoundation.com 
 comes back online.


As anyone else experiencing this?

Here is the patch I have applied to my local machine.

diff --git 
a/common/recipes-extended/openssl-qat/openssl-qat_0.4.9-009.bb 
 
b/common/recipes-extended/openssl-qat/openssl-qat_0.4.9-009.bb 


index e3d8ccc..31d8a8f 100644
--- a/common/recipes-extended/openssl-qat/openssl-qat_0.4.9-009.bb 

+++ b/common/recipes-extended/openssl-qat/openssl-qat_0.4.9-009.bb 


@@ -2,7 +2,7 @@ include openssl-qat.inc

 OPENSSL_VERSION = "1.0.1async"

-SRC_URI  += 
"git://opensslfoundation.com/openssl-async.git;branch=OpenSSL_1_0_1-async;rev=asynch_v0.4.9-009 
 
\
+SRC_URI  += 
"git://github.com/RIFTIO/openssl-async.git;branch=OpenSSL_1_0_1-async;rev=asynch_v0.4.9-009 
 
\

file://openssl-qat_0.4.9-009-openssl_qat-add-version-script.patch \
file://openssl-qat_0.4.9-009-openssl_qat-add-openssl-async-specific-symbols.patch 
\

              "




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

Re: [meta-intel] [meta-intel-qat][PATCH] qat: include qat17_1.0.3-42

[Cal Sullivan]

I now have write access to meta-intel-qat and have merged this as-is 
since its such a minor issue and this patch has been sitting so long.


Thanks,
Cal

On 12/07/2017 02:56 PM, Cal Sullivan wrote:

See reply below.

On 11/22/2017 12:27 AM, Syed Mohamad Fauzi, Syed Johan Arif wrote:
Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif 


---
  recipes-extended/qat/qat17.inc | 146 
+

  0-34-qat-remove-local-path-from-makefile.patch |  30 +
  ...rride-CC-LD-AR-only-when-it-is-not-define.patch |  34 +
  .../qat17/qat17_0.6.0-1-qat-fix-kernel-patch.patch |  33 +
  ...qat17_0.8.0-37-qat-added-include-dir-path.patch |  28 
  ...0-4-qat-add-install-target-and-add-folder.patch |  69 ++
  recipes-extended/qat/qat17_1.0.3-42.bb |  20 +++
  7 files changed, 360 insertions(+)
  create mode 100644 recipes-extended/qat/qat17.inc
  create mode 100644 
recipes-extended/qat/qat17/qat16_2.3.0-34-qat-remove-local-path-from-makefile.patch
  create mode 100644 
recipes-extended/qat/qat17/qat16_2.6.0-65-qat-override-CC-LD-AR-only-when-it-is-not-define.patch
  create mode 100644 
recipes-extended/qat/qat17/qat17_0.6.0-1-qat-fix-kernel-patch.patch
  create mode 100644 
recipes-extended/qat/qat17/qat17_0.8.0-37-qat-added-include-dir-path.patch
  create mode 100644 
recipes-extended/qat/qat17/qat17_0.9.0-4-qat-add-install-target-and-add-folder.patch

  create mode 100644 recipes-extended/qat/qat17_1.0.3-42.bb

diff --git a/recipes-extended/qat/qat17.inc 
b/recipes-extended/qat/qat17.inc

new file mode 100644
index 000..7793336
--- /dev/null
+++ b/recipes-extended/qat/qat17.inc
@@ -0,0 +1,146 @@
+DESCRIPTION = "Intel(r) QuickAssist Technology API"
+HOMEPAGE = 
"https://01.org/packet-processing/intel%C2%AE-quickassist-technology-drivers-and-patches";

+
+#Dual BSD and GPLv2 License
+LICENSE = "BSD & GPLv2"
+LIC_FILES_CHKSUM = "\
+ 
file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6 
\
+ 
file://${COMMON_LICENSE_DIR}/BSD;md5=3775480a712fc46a69647678acb234cb \

+    "
+DEPENDS += "boost"
+DEPENDS += "udev"
+DEPENDS += "zlib openssl"
+PROVIDES += "virtual/qat"
+
+SRC_URI="file://qat16_2.3.0-34-qat-fix-for-cross-compilation-issue.patch 
\

+ file://qat16_2.3.0-34-qat-remove-local-path-from-makefile.patch \
+ file://qat16_2.3.0-34-make-sure-CFLAGS-are-correct.patch \
+ "
Any reason to set SRC_URI here when its being overwritten in 
qat17_1.0.3-42.bb? Probably either set it here and _append it in the 
recipe, or don't set it here at all.


Otherwise, looks fine to me, and it passed a quick build test.

Thanks,
Cal


+#https://01.org/sites/default/files/page/qatmux.l.${PV}.tgz;name=qat
+COMPATIBLE_MACHINE = "crystalforest|intel-corei7-64|intel-core2-32"
+
+S = "${WORKDIR}"
+ICP_TOOLS = "accelcomp"
+SAMPLE_CODE_DIR = 
"${S}/quickassist/lookaside/access_layer/src/sample_code"

+export INSTALL_MOD_PATH = "${D}"
+export ICP_DRIVER_TYPE = "QAT1.7"
+export ICP_FIRMWARE_DIR="c3xxx"
+export ICP_ROOT = "${S}"
+export ICP_ENV_DIR = 
"${S}/quickassist/build_system/build_files/env_files"

+export ICP_BUILDSYSTEM_PATH = "${S}/quickassist/build_system"
+export ICP_TOOLS_TARGET = "${ICP_TOOLS}"
+export FUNC_PATH = 
"${ICP_ROOT}/quickassist/lookaside/access_layer/src/sample_code/functional"

+export INSTALL_FW_PATH = "${D}${base_libdir}/firmware"
+export KERNEL_SOURCE_ROOT = "${STAGING_KERNEL_DIR}"
+export ICP_BUILD_OUTPUT = "${D}"
+export DEST_LIBDIR = "${libdir}"
+export DEST_BINDIR = "${bindir}"
+export QAT_KERNEL_VER = "${KERNEL_VERSION}"
+export SAMPLE_BUILD_OUTPUT = "${D}"
+export MODULE_DIR = 
"${base_libdir}/modules/${KERNEL_VERSION}/kernel/drivers"

+export INSTALL_MOD_DIR = "${D}${base_libdir}/modules/${KERNEL_VERSION}"
+export KERNEL_BUILDDIR = "${STAGING_KERNEL_BUILDDIR}"
+export SC_EPOLL_DISABLED = "1"
+export WITH_UPSTREAM = "1"
+export WITH_CMDRV = "1"
+export KERNEL_SOURCE_DIR = "${ICP_ROOT}/quickassist/qat/"
+
+export BIN_LIST="qat_c3xxx.bin qat_c3xxx_a0.bin qat_c3xxx_mmp.bin 
qat_c62x.bin qat_c62x_mmp.bin"

+export BIN_DH895XCC="qat_895xcc.bin qat_mmp.bin"
+export BIN_C62X="qat_c62x.bin qat_c62x_mmp.bin"
+export BIN_C3XXX="qat_c3xxx.bin qat_c3xxx_mmp.bin"
+
+export 
KO_INTEL_QAT="${S}/quickassist/qat/drivers/crypto/qat/qat_common"
+export 
KO_QAT_DH895XCC="${S}/quickassist/qat/drivers/crypto/qat/qat_dh895xcc"
+export 
KO_QAT_DH895XCCVF="${S}/quickassist/qat/drivers/crypto/qat/qat_dh895xccvf"

+export KO_QAT_C62X="${S}/quickassist/qat/drivers/crypto/qat/qat_c62x&

Re: [meta-intel] [meta-intel-qat][PATCH] qat: include qat17_1.0.3-42

[Cal Sullivan]

See reply below.

On 11/22/2017 12:27 AM, Syed Mohamad Fauzi, Syed Johan Arif wrote:

Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif 

---
  recipes-extended/qat/qat17.inc | 146 +
  0-34-qat-remove-local-path-from-makefile.patch |  30 +
  ...rride-CC-LD-AR-only-when-it-is-not-define.patch |  34 +
  .../qat17/qat17_0.6.0-1-qat-fix-kernel-patch.patch |  33 +
  ...qat17_0.8.0-37-qat-added-include-dir-path.patch |  28 
  ...0-4-qat-add-install-target-and-add-folder.patch |  69 ++
  recipes-extended/qat/qat17_1.0.3-42.bb |  20 +++
  7 files changed, 360 insertions(+)
  create mode 100644 recipes-extended/qat/qat17.inc
  create mode 100644 
recipes-extended/qat/qat17/qat16_2.3.0-34-qat-remove-local-path-from-makefile.patch
  create mode 100644 
recipes-extended/qat/qat17/qat16_2.6.0-65-qat-override-CC-LD-AR-only-when-it-is-not-define.patch
  create mode 100644 
recipes-extended/qat/qat17/qat17_0.6.0-1-qat-fix-kernel-patch.patch
  create mode 100644 
recipes-extended/qat/qat17/qat17_0.8.0-37-qat-added-include-dir-path.patch
  create mode 100644 
recipes-extended/qat/qat17/qat17_0.9.0-4-qat-add-install-target-and-add-folder.patch
  create mode 100644 recipes-extended/qat/qat17_1.0.3-42.bb

diff --git a/recipes-extended/qat/qat17.inc b/recipes-extended/qat/qat17.inc
new file mode 100644
index 000..7793336
--- /dev/null
+++ b/recipes-extended/qat/qat17.inc
@@ -0,0 +1,146 @@
+DESCRIPTION = "Intel(r) QuickAssist Technology API"
+HOMEPAGE = 
"https://01.org/packet-processing/intel%C2%AE-quickassist-technology-drivers-and-patches";
+
+#Dual BSD and GPLv2 License
+LICENSE = "BSD & GPLv2"
+LIC_FILES_CHKSUM = "\
+
file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6 \
+
file://${COMMON_LICENSE_DIR}/BSD;md5=3775480a712fc46a69647678acb234cb \
+"
+DEPENDS += "boost"
+DEPENDS += "udev"
+DEPENDS += "zlib openssl"
+PROVIDES += "virtual/qat"
+
+SRC_URI="file://qat16_2.3.0-34-qat-fix-for-cross-compilation-issue.patch \
+ file://qat16_2.3.0-34-qat-remove-local-path-from-makefile.patch \
+ file://qat16_2.3.0-34-make-sure-CFLAGS-are-correct.patch \
+ "
Any reason to set SRC_URI here when its being overwritten in 
qat17_1.0.3-42.bb? Probably either set it here and _append it in the 
recipe, or don't set it here at all.


Otherwise, looks fine to me, and it passed a quick build test.

Thanks,
Cal


+#https://01.org/sites/default/files/page/qatmux.l.${PV}.tgz;name=qat
+COMPATIBLE_MACHINE = "crystalforest|intel-corei7-64|intel-core2-32"
+
+S = "${WORKDIR}"
+ICP_TOOLS = "accelcomp"
+SAMPLE_CODE_DIR = "${S}/quickassist/lookaside/access_layer/src/sample_code"
+export INSTALL_MOD_PATH = "${D}"
+export ICP_DRIVER_TYPE = "QAT1.7"
+export ICP_FIRMWARE_DIR="c3xxx"
+export ICP_ROOT = "${S}"
+export ICP_ENV_DIR = "${S}/quickassist/build_system/build_files/env_files"
+export ICP_BUILDSYSTEM_PATH = "${S}/quickassist/build_system"
+export ICP_TOOLS_TARGET = "${ICP_TOOLS}"
+export FUNC_PATH = 
"${ICP_ROOT}/quickassist/lookaside/access_layer/src/sample_code/functional"
+export INSTALL_FW_PATH = "${D}${base_libdir}/firmware"
+export KERNEL_SOURCE_ROOT = "${STAGING_KERNEL_DIR}"
+export ICP_BUILD_OUTPUT = "${D}"
+export DEST_LIBDIR = "${libdir}"
+export DEST_BINDIR = "${bindir}"
+export QAT_KERNEL_VER = "${KERNEL_VERSION}"
+export SAMPLE_BUILD_OUTPUT = "${D}"
+export MODULE_DIR = "${base_libdir}/modules/${KERNEL_VERSION}/kernel/drivers"
+export INSTALL_MOD_DIR = "${D}${base_libdir}/modules/${KERNEL_VERSION}"
+export KERNEL_BUILDDIR = "${STAGING_KERNEL_BUILDDIR}"
+export SC_EPOLL_DISABLED = "1"
+export WITH_UPSTREAM = "1"
+export WITH_CMDRV = "1"
+export KERNEL_SOURCE_DIR = "${ICP_ROOT}/quickassist/qat/"
+
+export BIN_LIST="qat_c3xxx.bin qat_c3xxx_a0.bin qat_c3xxx_mmp.bin qat_c62x.bin 
qat_c62x_mmp.bin"
+export BIN_DH895XCC="qat_895xcc.bin qat_mmp.bin"
+export BIN_C62X="qat_c62x.bin qat_c62x_mmp.bin"
+export BIN_C3XXX="qat_c3xxx.bin qat_c3xxx_mmp.bin"
+
+export KO_INTEL_QAT="${S}/quickassist/qat/drivers/crypto/qat/qat_common"
+export KO_QAT_DH895XCC="${S}/quickassist/qat/drivers/crypto/qat/qat_dh895xcc"
+export 
KO_QAT_DH895XCCVF="${S}/quickassist/qat/drivers/crypto/qat/qat_dh895xccvf"
+export KO_QAT_C62X="${S}/quickassist/qat/drivers/crypto/qat/qat_c62x"
+export KO_QAT_C62XVF="${S}/quickassist/qat/drivers/crypto/qat/qat_c62xvf"
+export KO_QAT_C3XXX="${S}/quickassist/qat/drivers/crypto/qat/qat_c3xxx"
+export KO_QAT_C3XXXVF="${S}/quickassist/qat/drivers/crypto/qat/qat_c3xxxvf"
+
+inherit module
+inherit update-rc.d
+INITSCRIPT_NAME = "qat_service"
+
+PARALLEL_MAKE = ""
+
+#To get around the double slashes in paths in QAT makefiles
+PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src"
+
+EXTRA_OEMAKE_append = " CFLAGS+='-fgnu89-inline -fPIC'"
+EXTRA_OEMAKE = "-e MAKEFLAGS="
+
+do_compile () {
+   export LD="${LD} --hash-style=gnu"
+   export MACHINE="${TARGET_ARCH}

Re: [meta-intel] Request for assistance - Yocto 2.0 - Changing Kernel UART support from 4 to 20

[Cal Sullivan]

I don't have hardware to test, but I believe I've found a few more 
necessary CONFIG options for this setup:


config SERIAL_8250_EXTENDED
bool "Extended 8250/16550 serial driver options"
depends on SERIAL_8250
help
  If you wish to use any non-standard features of the standard 
"dumb"

  driver, say Y here. This includes HUB6 support, shared serial
  interrupts, special multiport support, support for more than the
  four COM 1/2/3/4 boards, etc.

  Note that the answer to this question won't directly affect the
  kernel: saying N will just cause the configurator to skip all
  the questions about serial driver options. If unsure, say N.

config SERIAL_8250_SHARE_IRQ
bool "Support for sharing serial interrupts"
depends on SERIAL_8250_EXTENDED
help
  Some serial boards have hardware support which allows 
multiple dumb

  serial ports on the same board to share a single IRQ. To enable
  support for this in the serial driver, say Y here.

config SERIAL_8250_MANY_PORTS
bool "Support more than 4 legacy serial ports"
depends on SERIAL_8250_EXTENDED && !IA64
help
  Say Y here if you have dumb serial boards other than the four
  standard COM 1/2/3/4 ports. This may happen if you have an AST
  FourPort, Accent Async, Boca (read the Boca mini-HOWTO, 
available

  from ), or other custom
  serial port hardware which acts similar to standard serial port
  hardware. If you only use the standard COM 1/2/3/4 ports, you 
can
  say N here to save some memory. You can also say Y if you 
have an

  "intelligent" multiport card such as Cyclades, Digiboards, etc.

Try toggling these and report back.

Thanks,
Cal

On 10/16/2017 01:11 AM, Mike Maggs wrote:


Request for assistance - Yocto 2.0 - Changing Kernel UART support  
from 4 to 20


I am using Yocto 2.0 with Intel® Atom® Processor E3800 with Open 
Source Graphics (Valley Island) BSP from 
https://www.yoctoproject.org/downloads/bsps/jethro20/valley-island on 
My Custom SMARC Carrier using Adlink LEC-BTS SMARC Processor with 
Intel E3845 Processor with 2 x EXAR PCIe XR17V358s (16 UARTs) and 2 x 
Intel i210 Ethernet Controllers


I have done the following

 1. Verified that the Hardware is working using Fedora 18 with Exar
XR17V358 driver

cat /proc/tty/driver/xrserial

   serinfo:1.0 driver 
revision:


0: uart:XR17v35x mmio:0xD080 irq:16 tx:0 rx:0

1: uart:XR17v35x mmio:0xD0800400 irq:16 tx:0 rx:0

2: uart:XR17v35x mmio:0xD0800800 irq:16 tx:0 rx:0

3: uart:XR17v35x mmio:0xD0800C00 irq:16 tx:0 rx:0

4: uart:XR17v35x mmio:0xD0801000 irq:16 tx:0 rx:0

5: uart:XR17v35x mmio:0xD0801400 irq:16 tx:0 rx:0

6: uart:XR17v35x mmio:0xD0801800 irq:16 tx:0 rx:0

7: uart:XR17v35x mmio:0xD0801C00 irq:16 tx:0 rx:0

8: uart:XR17v35x mmio:0xD0802000 irq:16 tx:0 rx:0

9: uart:XR17v35x mmio:0xD0802400 irq:16 tx:0 rx:0

10: uart:XR17v35x mmio:0xD0802800 irq:16 tx:0 rx:0

11: uart:XR17v35x mmio:0xD0802C00 irq:16 tx:0 rx:0

12: uart:XR17v35x mmio:0xD0803000 irq:16 
tx:0 rx:0


13: uart:XR17v35x mmio:0xD0803400 irq:16 tx:0 rx:0

14: uart:XR17v35x mmio:0xD0803800 irq:16 tx:0 rx:0

15: uart:XR17v35x mmio:0xD0803C00 irq:16 tx:0 rx:0

2. Created a file named 8250.cfg in the files directory with the 
following content (without indentation):


CONFIG_SERIAL_8250=y

CONFIG_SERIAL_8250_CONSOLE=y

CONFIG_SERIAL_8250_PCI=y

CONFIG_SERIAL_8250_NR_UARTS=20

CONFIG_SERIAL_8250_RUNTIME_UARTS=20

CONFIG_SERIAL_CORE=y

CONFIG_SERIAL_CORE_CONSOLE=y

Next, include this configuration fragment and extend the FILESPATH 
variable in your .bbappend file:


FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI += "file://8250.cfg"

3. Kernel Config using menuconfig tool

Changed

CONFIG_SERIAL_8250_NR_UARTS=20

 CONFIG_SERIAL_8250_RUNTIME_UARTS=20

My other Kernel Config changes for the Intel i210 are working

4. Running Yocto Dylan Image (No support for Intel HSUART)

cat /proc/tty/driver/serial

serinfo:1.0 driver revision:

0: uart:16550A port:03F8 irq:4 tx:2069 rx:115 RTS|DTR

1: uart:XR17V35X mmio:0xD090 irq:16 tx:0 rx:0

 2: uart:XR17V35X mmio:0xD0900400 irq:16 tx:0 rx:0

3: uart:XR17V35X mmio:0xD0900800 irq:16 tx:0 rx:0

5. Running Yocto 2.0 Jethro Image (With support for Intel HSUART)

cat /proc/tty/driver/serial

serinfo:1.0 driver revision:

0: uart:16550A port:03F8 irq:4 tx:2042 rx:117 RTS|DTR

1: uart:16550A mmio:0xD0922000 irq:18 tx:0 rx:0 DSR|CD

2: uart:16550A mmio:0xD092 irq:19 tx:0 rx:0 DSR|CD

3: uart:XR17V35X mmio:0xD080 irq:16 tx:0 rx:0

Hoping that you will be able to help

Regards

Mike Maggs





-- 
___
meta-intel mailing list
meta-intel@yoctoproje

Re: [meta-intel] [PATCH] linux-intel/4.9: Update kernel SRCREVs

[Cal Sullivan]

It appears they do.
I reverted that patch and did a build. The snd_soc_skl module no longer 
fails, and sound over HDMI is working out of the box on my Joule.


I see that the snd_soc_skl module is still loaded automatically, which I 
find strange as I'd assume the _skl portion designates Skylake, but oh well.


---
Cal

On 10/17/2017 03:17 AM, Mikko Ylinen wrote:

Hi,


On 16/10/17 21:54, California Sullivan wrote:

Includes many backports to improve audio.


Do you know if they fix:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/common/recipes-kernel/linux/linux-intel.inc?id=075b81ae1bcc6bb3ebfee4015294e3b8a4ba22da 



-- Mikko


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

Re: [meta-intel] [PATCH] linux-firmware: remove qat from linux-firmware

[Cal Sullivan]

On 10/10/2017 07:38 AM, Wold, Saul wrote:

On Tue, 2017-10-10 at 17:32 +0800, Syed Mohamad Fauzi, Syed Johan Arif
wrote:

removed the following qat related binary files to avoid conflict when
incorporating the meta-intel-qat layer
1) qat_c3xxx_mmp.bin
2) qat_c62x.bin
3) qat_c62x_mmp.bin


Is there a reason that the upstream linux-firmware is not updated with
the new or different firmware?  Where is the firmware coming from?

Also will there be updates to the openssl-qat?

Sau!


Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif

---
  .../linux-firmware/linux-firmware_git.bbappend | 14
++
  1 file changed, 14 insertions(+)
  create mode 100644 common/recipes-kernel/linux-firmware/linux-
firmware_git.bbappend

diff --git a/common/recipes-kernel/linux-firmware/linux-
firmware_git.bbappend b/common/recipes-kernel/linux-firmware/linux-
firmware_git.bbappend
new file mode 100644
index 000..2f8fe3d
--- /dev/null
+++ b/common/recipes-kernel/linux-firmware/linux-
firmware_git.bbappend
@@ -0,0 +1,14 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+do_install_append() {
+
+   rm -rf ${D}${nonarch_base_libdir}/firmware/qat_c3xxx.bin
+   rm -rf ${D}${nonarch_base_libdir}/firmware/qat_c3xxx_mmp.bin
+   rm -rf ${D}${nonarch_base_libdir}/firmware/qat_c62x.bin
+   rm -rf ${D}${nonarch_base_libdir}/firmware/qat_c62x_mmp.bin
+}
+
+FILES_${PN}_remove +=
"${nonarch_base_libdir}/firmware/qat_c3xxx.bin"
+FILES_${PN}_remove +=
"${nonarch_base_libdir}/firmware/qat_c3xxx_mmp.bin"
+FILES_${PN}_remove += "${nonarch_base_libdir}/firmware/qat_c62x.bin"
+FILES_${PN}_remove +=
"${nonarch_base_libdir}/firmware/qat_c62x_mmp.bin"
--
1.9.1

Also, for meta-intel to stay being considered a Yocto Project Compatible 
layer, values set in OE-core should not be changed without the use of a 
MACHINEOVERRIDE. You will need to use the -intel-x86-common override on 
all these if it is to be accepted.


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

Re: [meta-intel] [PATCH] linux-firmware: remove bbappend

[Cal Sullivan]

Yep, that's a good idea. I'll send out a v2 including some comments in 
backport-iwlwifi.


---
Cal

On 09/26/2017 10:23 PM, Mikko Ylinen wrote:



On 26/09/17 21:40, California Sullivan wrote:

With the SRCREV bump in OE-core, all the firmware bits we need are
already included so we don't need this anymore.


With this removal we loose important documentation about
what backport-iwlwifi might need. Perhaps move some of
the comments in this bbappend to backport-iwlwifi_git.bb to
remind the developers who update iwlwifi's LinuxCore to check
backport-iwlwifi gets the right firmware blob in the build.

-- Mikko





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

Re: [meta-intel] [PATCH] uefi-comboapp.bbclass: support multiple UEFI combo apps + fixes

[Cal Sullivan]

On 07/18/2017 02:04 PM, Patrick Ohly wrote:

On Tue, 2017-07-18 at 13:44 -0700, Cal Sullivan wrote:

-do_uefiapp_sign[depends] += "${PN}:do_uefiapp_deploy \
- sbsigntool-native:do_populate_sysroot"
+# This is intentionally split into different parts. This way,

derived

+# classes or images can extend the individual parts. We can also

use

+# whatever language (shell script or Python) is more suitable.
+python do_uefiapp() {
+bb.build.exec_func('create_uefiapps', d)
+bb.build.exec_func('sign_uefiapps', d)
+}

I'd like to move the signing portion to its own flexible bbclass so it
can be used elsewhere (systemd-boot, kernel, eventually shim). Would
something like what I sent in my last RFC be flexible enough to suite
refkit's needs?

You mean the "Super simple secure boot implementation not requiring
combo app" approach? I'm still concerned about choosing the initramfs,
see my reply in that email.
In this instance I'm only talking about the first of the four patches in 
that series which adds the signing bbclass.



  Adding the signing portion like this would make my goal a bit harder.

The code can always be refactored, as long as the end-result is the same
(do_uefiapp_deploy puts signed bootx64.efi into the rootfs).
Shouldn't be an issue. The bbclass should be able to handle signing any 
valid binary at any point.




uefi-comboapp.bbclass is now in meta-intel master. I think it should be
fixed or reverted before releasing M2. I don't have a preference either
way.
With your patch it should be okay functionally and usable in refkit, 
which will get us through M2. I'll work on generalizing the signing 
portion better before moving on to other secure boot implementations, 
but these will need to wait until after M2.


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

Re: [meta-intel] [PATCH RFC 0/4] Super simple secure boot implementation not requiring combo app

[Cal Sullivan]

On 07/18/2017 01:58 PM, Patrick Ohly wrote:

On Tue, 2017-07-18 at 13:32 -0700, Cal Sullivan wrote:

On 07/16/2017 11:26 PM, Patrick Ohly wrote:

On Fri, 2017-07-14 at 19:11 -0700, California Sullivan wrote:

I'm not sure why I never tried just signing the kernel and systemd-boot,
but it works. If either one is not signed, it causes gives a security
violation error.

A con of this implementation is that unlike the combo app, we don't
inherently validate the initrd. In the future we could require that
an initrd is not used with secure boot unless the combo app is chosen.

A lot of functionality in refkit (and elsewhere) depends on an an
initramfs, like setting up dm-verity, dm-crypt/LUKS and OSTree. I
consider not supporting an initramfs a deal breaker. It might be good
enough for some systems, but I'm not sure about that.


I misspoke a bit in my message here. The combo app essentially uses an
initramfs built into the kernel rather than an initrd, and such a thing
should still work with this method (via INITRAMFS_IMAGE_BUNDLE and
INITRAMFS_IMAGE variables).

This puts the initramfs into the kernel, right?

That's less flexible than the combo app, because with the combo app one
can define kernel and initramfs separately for each image, whereas
putting the initramfs into the kernel can one be done once per build,
i.e. the same initramfs must be used for the entire build.

Multiconfig might help here, but is probably harder to get right and
manage.



I believe a different initramfs can be defined for each kernel. That's 
still very good though, as you'd need a different kernel recipe for each 
image target you want a different initramfs on. Conceptually it actually 
makes sense since the resulting kernel is different, but it could 
quickly get out of hand when we start getting requests for every kernel 
+ initramfs combination under the sun.


---
Cal



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

Re: [meta-intel] [PATCH] uefi-comboapp.bbclass: support multiple UEFI combo apps + fixes

[Cal Sullivan]

On 07/18/2017 12:26 PM, Patrick Ohly wrote:

The original code in intel-iot-refkit allows to create more than one
UEFI combo app and uses that to create one for removable media and one
for fixed media (after installation), with different boot=PARTUUID=xxx
parameters. This way, an installed image never ended up booting from
the install media.

uefi-comboapp.bbclass now supports the same feature, with
create_uefiapp() as the API function that can be used to create
additional UEFI apps and create_uefiapps as the method where the call
can be added.

In addition, several shortcomings are getting addressed:
- A UEFI combo app must be stored under a name that is specific
   to the image for which it gets created, otherwise different
   image recipes end up overwriting (or using) files from other
   images.
- Signing must be done after creating the apps and before deploying
   them, otherwise the unsigned apps get copied to the image when
   using do_uefiapp_deploy.
- The common code for deployment is now in uefiapp_deploy_at.
- $dest is used instead of ${DEST} because the latter might get
   expanded by bitbake.
- Because do_uefiapp always had to run anew to produce the
   clean, unsigned input for do_uefiapp_sign, having two different
   tasks just added unnecessary complexity. Now all code is in
   do_uefiapp.
- Old files matching the output pattern get removed explicitly,
   because they might not get overwritten when the optional
   app suffix changes between builds, or when the task fails
   in the middle.

Signed-off-by: Patrick Ohly 
---
  classes/uefi-comboapp.bbclass | 71 
  1 file changed, 48 insertions(+), 23 deletions(-)

diff --git a/classes/uefi-comboapp.bbclass b/classes/uefi-comboapp.bbclass
index 7719686..fc7e1b6 100644
--- a/classes/uefi-comboapp.bbclass
+++ b/classes/uefi-comboapp.bbclass
@@ -32,12 +32,13 @@ do_uefiapp[depends] += "${@ 
'${INITRD_IMAGE}:do_image_complete' if d.getVar('INI
  #   - the kernel
  #   - an initramfs (optional)
  
-python do_uefiapp() {

+def create_uefiapp(d, uuid=None, app_suffix=''):
  import glob, re
  from subprocess import check_call
  
  build_dir = d.getVar('B')

  deploy_dir_image = d.getVar('DEPLOY_DIR_IMAGE')
+image_link_name = d.getVar('IMAGE_LINK_NAME')
  
  cmdline = '%s/cmdline.txt' % build_dir

  linux = '%s/%s' % (deploy_dir_image, d.getVar('KERNEL_IMAGETYPE'))
@@ -45,8 +46,9 @@ python do_uefiapp() {
  
  stub_path = '%s/linux*.efi.stub' % deploy_dir_image

  stub = glob.glob(stub_path)[0]
-app = re.sub(r"\S*(ia32|x64)(.efi)\S*", r"boot\1\2", 
os.path.basename(stub))
-executable = '%s/%s' % (deploy_dir_image, app)
+m = re.match(r"\S*(ia32|x64)(.efi)\S*", os.path.basename(stub))
+app = "boot%s%s%s" % (m.group(1), app_suffix, m.group(2))
+executable = '%s/%s.%s' % (deploy_dir_image, image_link_name, app)
  
  if d.getVar('INITRD_LIVE'):

  with open(initrd, 'wb') as dst:
@@ -57,7 +59,6 @@ python do_uefiapp() {
  else:
  initrd_cmd = ""
  
-uuid = d.getVar('DISK_SIGNATURE_UUID')

  root = 'root=PARTUUID=%s' % uuid if uuid else ''
  
  with open(cmdline, 'w') as f:

@@ -70,21 +71,22 @@ python do_uefiapp() {
  (cmdline, linux, initrd_cmd, stub, executable)
  
  check_call(objcopy_cmd, shell=True)

-}
  
-do_uefiapp[vardeps] += "APPEND DISK_SIGNATURE_UUID INITRD_LIVE KERNEL_IMAGETYPE"

-
-do_uefiapp_deploy() {
-rm -rf ${IMAGE_ROOTFS}/boot/*
-mkdir -p ${IMAGE_ROOTFS}/boot/EFI/BOOT
-cp  --preserve=timestamps ${DEPLOY_DIR_IMAGE}/boot*.efi 
${IMAGE_ROOTFS}/boot/EFI/BOOT/
+python create_uefiapps () {
+# We must clean up anything that matches the expected output pattern, to 
ensure that
+# the next steps do not accidentally use old files.
+import glob
+pattern = d.expand('${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.boot*.efi')
+for old_efi in glob.glob(pattern):
+os.unlink(old_efi)
+uuid = d.getVar('DISK_SIGNATURE_UUID')
+create_uefiapp(d, uuid=uuid)
  }
  
-do_uefiapp_deploy[depends] += "${PN}:do_uefiapp"

-
-do_uefiapp_sign() {
-if [ -f ${UEFIAPP_SIGNING_KEY} ] && [ -f ${UEFIAPP_SIGNING_CERT} ]; then
-for i in `find ${DEPLOY_DIR_IMAGE}/ -name 'boot*.efi'`; do
+sign_uefiapps () {
+if ${@ bb.utils.contains('IMAGE_FEATURES', 'secureboot', 'true', 'false', d) } 
&&
+   [ -f ${UEFIAPP_SIGNING_KEY} ] && [ -f ${UEFIAPP_SIGNING_CERT} ]; then
+for i in `find ${DEPLOY_DIR_IMAGE}/ -name 
'${IMAGE_LINK_NAME}.boot*.efi'`; do
  sbsign --key ${UEFIAPP_SIGNING_KEY} --cert 
${UEFIAPP_SIGNING_CERT} $i
  sbverify --cert ${UEFIAPP_SIGNING_CERT} $i.signed
  mv $i.signed $i
@@ -92,8 +94,35 @@ do_uefiapp_sign() {
  fi
  }
  
-do_uefiapp_sign[depends] += "${PN}:do_uefiapp_deploy \

- sbsigntool-native:do_populate_sysroot"
+# This is intentionally split into different parts. This way, derived
+# classes or i

Re: [meta-intel] [PATCH RFC 0/4] Super simple secure boot implementation not requiring combo app

[Cal Sullivan]

On 07/16/2017 11:26 PM, Patrick Ohly wrote:

On Fri, 2017-07-14 at 19:11 -0700, California Sullivan wrote:

I'm not sure why I never tried just signing the kernel and systemd-boot,
but it works. If either one is not signed, it causes gives a security
violation error.

A con of this implementation is that unlike the combo app, we don't
inherently validate the initrd. In the future we could require that
an initrd is not used with secure boot unless the combo app is chosen.

A lot of functionality in refkit (and elsewhere) depends on an an
initramfs, like setting up dm-verity, dm-crypt/LUKS and OSTree. I
consider not supporting an initramfs a deal breaker. It might be good
enough for some systems, but I'm not sure about that.

I misspoke a bit in my message here. The combo app essentially uses an 
initramfs built into the kernel rather than an initrd, and such a thing 
should still work with this method (via INITRAMFS_IMAGE_BUNDLE and 
INITRAMFS_IMAGE variables). A separate initrd (like what you see when 
using an hddimg with a normal bootloader) would not be secure, and might 
be something to not allow when secure boot is enabled.


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

Re: [meta-intel] [PATCH RFC 0/4] Super simple secure boot implementation not requiring combo app

[Cal Sullivan]

+ Patrick (mistyped email address).

---
Cal

On 07/14/2017 07:11 PM, California Sullivan wrote:

I'm not sure why I never tried just signing the kernel and systemd-boot,
but it works. If either one is not signed, it causes gives a security
violation error.

A con of this implementation is that unlike the combo app, we don't
inherently validate the initrd. In the future we could require that
an initrd is not used with secure boot unless the combo app is chosen.

Obviously some cleanup is needed on my old work should we go this route,
but its the end of a friday and I wanted to get some feedback on this.

If you want to test it out you can pull my branch clsulliv/secureboot-simple.

---
Cal


California Sullivan (4):
   classes: Add uefi-sign.bbclass
   systemd-boot: Add uefi-sign bbclass to sign bootloader
   linux-intel: Add uefi-sign bbclass to sign kernel
   meta-intel.inc: Add secureboot to valid IMAGE_FEATURES

  classes/uefi-sign.bbclass  | 52 ++
  .../systemd-boot/systemd-boot_%.bbappend   |  3 ++
  common/recipes-kernel/linux/linux-intel_4.9.bb |  5 ++-
  conf/machine/include/meta-intel.inc|  2 +
  4 files changed, 61 insertions(+), 1 deletion(-)
  create mode 100644 classes/uefi-sign.bbclass



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

Re: [meta-intel] [PATCH RFC 2/4] systemd-boot_%.bbappend: compile and deploy EFI stub

[Cal Sullivan]

Unfortunately this adds another variable to the mix, and it would need 
to be changed in global context rather than recipe context, so in order 
to build an efi app that depends on it we'd need to add both 
IMAGE_CLASSES += "uefi_comboapp" and SYSTEMD_BOOT_BUILD_TARGET = "stub" 
to a .conf file.


I was thinking of adding some hanging functions we could depend on, but 
that would break package creation without a lot of manual work in the 
recipe.


Another option would be a standalone systemd-boot-stub recipe.

For now I'm going to send my V2 with this the same, but know I'm still 
giving this thought.


Thanks,
Cal

On 06/16/2017 04:39 AM, Mikko Ylinen wrote:



On 14/06/17 00:37, Cal Sullivan wrote:



On 06/12/2017 09:22 AM, Wold, Saul wrote:

On Fri, 2017-06-09 at 18:30 -0700, California Sullivan wrote:

The EFI stub can be used to directly boot a kernel + initramfs.
This addition was taken from meta-refkit.

Signed-off-by: California Sullivan 
---
  common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend | 8 
  1 file changed, 8 insertions(+)

diff --git a/common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
b/common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
index f13763b..6cb7369 100644
--- a/common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
+++ b/common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
@@ -25,3 +25,11 @@ SRC_URI_append_intel-x86-common = " \
  "
PACKAGE_ARCH_intel-x86-common = "${INTEL_COMMON_PACKAGE_ARCH}"
+
+do_compile_append() {
+oe_runmake linux${SYSTEMD_BOOT_EFI_ARCH}.efi.stub
+}
+
+do_deploy_append() {
+install ${B}/linux*.efi.stub ${DEPLOYDIR}
+}

Do these changes make it always build and deploy a stub binary? Should
this be conditional?

It does, but its really small.

I'm not sure what kind of conditional we could use but still have the 
recipe look clean. The uefi-comboapp bbclass is inherited by an image 
one way or another, so its variables are in recipe context and won't 
affect the outside world. We'd need to check EFI_PROVIDER or 
something, but EFI_PROVIDER is a live-image-ism, and won't 
necessarily be set when building a wic image, for example.




Long time ago I experimented with something like this but
never sent it out to OE-Core:

diff --git a/meta/recipes-bsp/systemd-boot/systemd-boot_232.bb 
b/meta/recipes-bsp/systemd-boot/systemd-boot_232.bb

index 0471ce2..695d0fc 100644
--- a/meta/recipes-bsp/systemd-boot/systemd-boot_232.bb
+++ b/meta/recipes-bsp/systemd-boot/systemd-boot_232.bb
@@ -19,13 +19,23 @@ EXTRA_OECONF = " --enable-gnuefi \
 TUNE_CCARGS_remove = "-mfpmath=sse"
 COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux"

+do_compile[vardeps] += "SYSTEMD_BOOT_BUILD_TARGET"
+
+# Configure whether to build the bootloader or the EFI stub.
+# The latter option is built when setting the variable to "stub".
+SYSTEMD_BOOT_BUILD_TARGET ??= "systemd-boot"
+
 do_compile() {
SYSTEMD_BOOT_EFI_ARCH="ia32"
if [ "${TARGET_ARCH}" = "x86_64" ]; then
SYSTEMD_BOOT_EFI_ARCH="x64"
fi

-   oe_runmake systemd-boot${SYSTEMD_BOOT_EFI_ARCH}.efi
+   if [ "${SYSTEMD_BOOT_BUILD_TARGET}" = "stub" ]; then
+   oe_runmake linux${SYSTEMD_BOOT_EFI_ARCH}.efi.stub
+   else
+   oe_runmake systemd-boot${SYSTEMD_BOOT_EFI_ARCH}.efi
+   fi
 }

 do_install() {
@@ -34,6 +44,6 @@ do_install() {
 }

 do_deploy () {
-   install ${B}/systemd-boot*.efi ${DEPLOYDIR}
+   install ${B}/*.efi* ${DEPLOYDIR}
 }
 addtask deploy before do_build after do_compile


-- Mikko


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

Re: [meta-intel] [PATCH RFC] systemd-boot_%.bbappend: Add stub command line modifications patch

[Cal Sullivan]

This was supposed to be in reply to Patrick's comment on patch 1/4 of my 
previous set, but I missed a letter at the end of the message ID. Oops.


---
Cal

On 06/14/2017 06:47 PM, California Sullivan wrote:

Allows you to modify the command line when called from EFI shell
instead of the entire command line getting replaced.

Signed-off-by: California Sullivan 
---
I liked this idea so I gave it a shot. Let me know what you think.
Commit message is a WIP. Its getting late but I'd like some feedback.

  ...ub-allow-smarter-command-line-modificatio.patch | 132 +
  .../systemd-boot/systemd-boot_%.bbappend   |   1 +
  2 files changed, 133 insertions(+)
  create mode 100644 
common/recipes-bsp/systemd-boot/systemd-boot/0001-boot-efi-stub-allow-smarter-command-line-modificatio.patch

diff --git 
a/common/recipes-bsp/systemd-boot/systemd-boot/0001-boot-efi-stub-allow-smarter-command-line-modificatio.patch
 
b/common/recipes-bsp/systemd-boot/systemd-boot/0001-boot-efi-stub-allow-smarter-command-line-modificatio.patch
new file mode 100644
index 000..9cc92c9
--- /dev/null
+++ 
b/common/recipes-bsp/systemd-boot/systemd-boot/0001-boot-efi-stub-allow-smarter-command-line-modificatio.patch
@@ -0,0 +1,132 @@
+From 47a4ce351911625f227b8b29d9c307d5c32fd32f Mon Sep 17 00:00:00 2001
+From: California Sullivan 
+Date: Wed, 14 Jun 2017 17:33:30 -0700
+Subject: [PATCH] boot: efi: stub: allow smarter command line modifications
+
+Currently, the command line is replaced with anything that ends up in
+LoadOptions. LoadOptions gets populated by the firmware, and EFI shell
+command line information when running a binary. This includes the name
+of the binary itself, so it will usually break booting from the EFI
+shell.
+
+Instead, have LoadOptions modify the command line in the following way:
+
+bootx64 root=/dev/sda -> prepend the command line (default)
+bootx64 ^console=/dev/tty0 -> prepend the command line (explicit)
+bootx64 $console=/dev/tty0 -> append the command line
+bootx64 !console=/dev/tty0 root=/dev/sda -> replace the command line
+
+The '^', '$' and '!' characters act as sentinel values, telling the EFI
+stub how to handle LoadOptions values, as well as indicating where
+command line modifications in LoadOptions should begin.
+
+Note that with the default case, bootx64 will end up in the kernel
+command line, as we use the sentinel values to decide where to begin the
+command line modifications.
+
+Signed-off-by: California Sullivan 
+---
+ src/boot/efi/stub.c | 82 ++---
+ 1 file changed, 78 insertions(+), 4 deletions(-)
+
+diff --git a/src/boot/efi/stub.c b/src/boot/efi/stub.c
+index 74e95fd..a4b34a2 100644
+--- a/src/boot/efi/stub.c
 b/src/boot/efi/stub.c
+@@ -93,15 +93,89 @@ EFI_STATUS efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE 
*sys_table) {
+ /* if we are not in secure boot mode, accept a custom command line 
and replace the built-in one */
+ if (!secure && loaded_image->LoadOptionsSize > 0 && *(CHAR16 
*)loaded_image->LoadOptions != 0) {
+ CHAR16 *options;
++CHAR8 mode;
+ CHAR8 *line;
++UINTN options_len;
++UINTN total_len;
+ UINTN i;
++UINTN j;
++UINTN k;
+
+ options = (CHAR16 *)loaded_image->LoadOptions;
+-cmdline_len = (loaded_image->LoadOptionsSize / 
sizeof(CHAR16)) * sizeof(CHAR8);
+-line = AllocatePool(cmdline_len);
+-for (i = 0; i < cmdline_len; i++)
+-line[i] = options[i];
++options_len = (loaded_image->LoadOptionsSize / 
sizeof(CHAR16)) * sizeof(CHAR8);
++
++mode = '?';
++/* walk through options to find sentinel values indicating 
alternative modes
++* also use this index to begin the command line changes
++* this lets us avoid adding the binary name to the command 
line */
++for(i = 0; i < options_len; i++) {
++if (options[i] == '$' ||
++options[i] == '!' ||
++options[i] == '^') {
++mode = options[i];
++break;
++}
++}
++
++switch(mode) {
++
++/* append to the cmdline */
++case '$':
++total_len = cmdline_len + options_len - i + 1;
++i++;
++line = AllocatePool(total_len);
++for (j = 0; j < cmdline_len; j++)
++line[j] = cmdline[j];
++
++line[j++] = ' ';
++
++for (k = 0; i + k < options_len && j + k < total_len; 
k++)
++line[j + k] = options[i + k];
++
++

Re: [meta-intel] [PATCH RFC 0/4] First pass at combo app and secure boot support

[Cal Sullivan]

On 06/13/2017 11:24 PM, Patrick Ohly wrote:

On Tue, 2017-06-13 at 14:15 -0700, Cal Sullivan wrote:

On 06/12/2017 01:57 AM, Patrick Ohly wrote:

On Fri, 2017-06-09 at 18:30 -0700, California Sullivan wrote:

While its possible to use wic with it thanks to the uefiapp_deploy
function, the init scripts in the initramfs we currently ship are made
for live images, and will attempt to mount and boot a rootfs.img, which
will fail.

Why does it fail? Aside from the different content of bootx64.efi, I'd
expect the rest of the disk image to be unchanged, so I can't imagine
why it might fail.

Refkit uses its own initramfs which uses the initramfs-framework
scripts. These handle mounting and booting a root partition correctly.
Core-image-minimal-initramfs uses initramfs-live-boot, which only seems
to work with a rootfs.img placed in the EFI FAT partition.

Yes, I know. But why does choosing the UEFI combo app as bootx64.efi
influence the rootfs.img? In other words, why is it not where the
initramfs-live-boot expects it?

Ah, I understand your question now.
Choosing the UEFI combo app doesn't influence the rootfs.img. The issue 
is that rootfs.img is something made by image-live.bbclass (well, its 
the rootfs filesystem renamed to rootfs.img), which we don't have when 
building a wic image. Wic images in OE-core don't seem to be using an 
initrd or initramfs at all right now, so they don't have this issue.





The second issue is that this class is dependant on an INTIRD_IMAGE.
This means that the class cannot be added via IMAGE_CLASSES in a global
context (such as local.conf), as it would create a circular dependency.
So, in order to apply this while using wic alone, we would need to
conditionally inherit it on every non-initrd/initramfs image target
through bbappends, which would be a little messy. I've already tried
that workaround successfully, but I'm currently brainstorming solutions
looking for something cleaner.

This is presumably a result of changing INITRD_LIVE? It might be better
to not rely or affect image-live.bbclass at all.

Also note that the comment about that particular change is about aspects
("copying to rootfs", "swupd bundle support") which might not be
applicable anymore.


This is due to the do_uefiapp[depends] section containing
${INITRD_IMAGE}:do_image_complete. Inheriting the class directly, the
INITRD_LIVE addition shouldn't do anything, as we don't inherit
image-live in that case.

do_uefiapp shouldn't be needed in an initramfs image, even when
uefi-comboapp.bbclass happens to be inherited for all images. That's the
real issue that needs to be solved, the circular dependency is just a
side effect.
Right. It seems like right now we don't have a uniform way to 
differentiate them, however. Checking IMAGE_FSTYPES could work, as an 
initramfs image will generally not have wic or hddimg, but that may be 
more of a workaround than a solution. I think OE-core could use a way to 
easily differentiate between the two, and variables similar to 
IMAGE_CLASSES, but only applying to one or the other.

Apparently EFI_PROVIDER is some kind of configuration option which tells
image creation code about the boot loader. I've not found documentation
about that mechanism. Is that something that could also be used for UEFI
combo app, with or without wic?

EFI_PROVIDER is inherited when building live images. If we have both wic 
and hddimg (or live) in IMAGE_FSTYPES, then it does work thanks to this, 
but its not behavior we should rely on.


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

Re: [meta-intel] [PATCH RFC 2/4] systemd-boot_%.bbappend: compile and deploy EFI stub

[Cal Sullivan]

On 06/12/2017 09:22 AM, Wold, Saul wrote:

On Fri, 2017-06-09 at 18:30 -0700, California Sullivan wrote:

The EFI stub can be used to directly boot a kernel + initramfs.
This addition was taken from meta-refkit.

Signed-off-by: California Sullivan 
---
  common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend | 8 
  1 file changed, 8 insertions(+)

diff --git a/common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
b/common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
index f13763b..6cb7369 100644
--- a/common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
+++ b/common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
@@ -25,3 +25,11 @@ SRC_URI_append_intel-x86-common = " \
  "
  
  PACKAGE_ARCH_intel-x86-common = "${INTEL_COMMON_PACKAGE_ARCH}"

+
+do_compile_append() {
+   oe_runmake linux${SYSTEMD_BOOT_EFI_ARCH}.efi.stub
+}
+
+do_deploy_append() {
+   install ${B}/linux*.efi.stub ${DEPLOYDIR}
+}

Do these changes make it always build and deploy a stub binary? Should
this be conditional?

It does, but its really small.

I'm not sure what kind of conditional we could use but still have the 
recipe look clean. The uefi-comboapp bbclass is inherited by an image 
one way or another, so its variables are in recipe context and won't 
affect the outside world. We'd need to check EFI_PROVIDER or something, 
but EFI_PROVIDER is a live-image-ism, and won't necessarily be set when 
building a wic image, for example.


---
Cal



Sau!


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

Re: [meta-intel] [PATCH RFC 0/4] First pass at combo app and secure boot support

[Cal Sullivan]

On 06/12/2017 01:57 AM, Patrick Ohly wrote:

On Fri, 2017-06-09 at 18:30 -0700, California Sullivan wrote:

While its possible to use wic with it thanks to the uefiapp_deploy
function, the init scripts in the initramfs we currently ship are made
for live images, and will attempt to mount and boot a rootfs.img, which
will fail.

Why does it fail? Aside from the different content of bootx64.efi, I'd
expect the rest of the disk image to be unchanged, so I can't imagine
why it might fail.
Refkit uses its own initramfs which uses the initramfs-framework 
scripts. These handle mounting and booting a root partition correctly. 
Core-image-minimal-initramfs uses initramfs-live-boot, which only seems 
to work with a rootfs.img placed in the EFI FAT partition.



The second issue is that this class is dependant on an INTIRD_IMAGE.
This means that the class cannot be added via IMAGE_CLASSES in a global
context (such as local.conf), as it would create a circular dependency.
So, in order to apply this while using wic alone, we would need to
conditionally inherit it on every non-initrd/initramfs image target
through bbappends, which would be a little messy. I've already tried
that workaround successfully, but I'm currently brainstorming solutions
looking for something cleaner.

This is presumably a result of changing INITRD_LIVE? It might be better
to not rely or affect image-live.bbclass at all.

Also note that the comment about that particular change is about aspects
("copying to rootfs", "swupd bundle support") which might not be
applicable anymore.

This is due to the do_uefiapp[depends] section containing 
${INITRD_IMAGE}:do_image_complete. Inheriting the class directly, the 
INITRD_LIVE addition shouldn't do anything, as we don't inherit 
image-live in that case.


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

Re: [meta-intel] [PATCH RFC 1/4] systemd-boot: Add patch to systemd boot stub to fix kernel command line

[Cal Sullivan]

On 06/13/2017 12:27 AM, Patrick Ohly wrote:

On Tue, 2017-06-13 at 10:07 +0300, Jussi Laako wrote:

On 12.06.2017 19:16, Wold, Saul wrote:

Is it possible this would be accepted upstream?  or possibly a way to
make it more acceptable upstream check for an "append" check to know it
append vs replace?

I think it may still be good idea to make it "prepend" instead of
"append" to allow changing console setting. IIRC, kernel uses the first
console specified on the command line...

Does it always use the first value? For example, for "root=/dev/sda
root=/dev/sdb", which one will it use?

I'll try this out and get back to you.
I'm leaning towards changing it to prepend for the default case, as the 
console is one of the more likely things to be changed in my opinion.


---
Cal



I agree that prepend makes more sense for console. I'm just worried that
we might need append for other variables, thanks to inconsistent boot
parameter handling in the kernel :-/

So perhaps RMC needs to support both for values added by database
entries.

But that wouldn't help with command line parameters, unless we extend
the parsing and handling of those. Something like:

bootx64.efi root=/dev/sda -> append (the default)
bootx64.efi ^console=/dev/tty0 -> prepend console=/dev/tty0 (default changed 
with ^)
bootx64.efi $console=/dev/tty0 -> append console=/dev/tty0 (default explicitly 
chosen with $)
bootx64.efi ! console=/dev/tty0 root=/dev/sda -> replace boot parameters with 
those given on the command line



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

Re: [meta-intel] [PATCH 1/2] meta-tlk: merge linux-yocto_tlk.inc with bbappend

[Cal Sullivan]

Hi Bruce,

I noticed that you originally created the meta-tlk layer. Will this 
change conflict with anything you guys are doing?


Thanks,
Cal

On 05/30/2017 03:04 PM, California Sullivan wrote:

Only one recipe uses this .inc file, and we need to add a linux-intel
bbappend that is slightly different, so this .inc file will not be
appropriate there either. Instead just keep everything in the bbappend.

We can reuse the time-limited-kernel config fragment, so move that to a
neutral location as well.

Signed-off-by: California Sullivan 
---
  meta-tlk/recipes-kernel/linux/files/time-limited-kernel.cfg   | 3 +++
  meta-tlk/recipes-kernel/linux/linux-yocto/time-limited-kernel.cfg | 3 ---
  meta-tlk/recipes-kernel/linux/linux-yocto_%.bbappend  | 3 ++-
  meta-tlk/recipes-kernel/linux/linux-yocto_tlk.inc | 2 --
  4 files changed, 5 insertions(+), 6 deletions(-)
  create mode 100644 meta-tlk/recipes-kernel/linux/files/time-limited-kernel.cfg
  delete mode 100644 
meta-tlk/recipes-kernel/linux/linux-yocto/time-limited-kernel.cfg
  delete mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_tlk.inc

diff --git a/meta-tlk/recipes-kernel/linux/files/time-limited-kernel.cfg 
b/meta-tlk/recipes-kernel/linux/files/time-limited-kernel.cfg
new file mode 100644
index 000..44f4bea
--- /dev/null
+++ b/meta-tlk/recipes-kernel/linux/files/time-limited-kernel.cfg
@@ -0,0 +1,3 @@
+CONFIG_UPTIME_LIMITED_KERNEL=y
+CONFIG_UPTIME_LIMIT_DURATION=14400
+CONFIG_UPTIME_LIMIT_KERNEL_REBOOT=y
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto/time-limited-kernel.cfg 
b/meta-tlk/recipes-kernel/linux/linux-yocto/time-limited-kernel.cfg
deleted file mode 100644
index 44f4bea..000
--- a/meta-tlk/recipes-kernel/linux/linux-yocto/time-limited-kernel.cfg
+++ /dev/null
@@ -1,3 +0,0 @@
-CONFIG_UPTIME_LIMITED_KERNEL=y
-CONFIG_UPTIME_LIMIT_DURATION=14400
-CONFIG_UPTIME_LIMIT_KERNEL_REBOOT=y
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_%.bbappend 
b/meta-tlk/recipes-kernel/linux/linux-yocto_%.bbappend
index f580168..3008512 100644
--- a/meta-tlk/recipes-kernel/linux/linux-yocto_%.bbappend
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -1 +1,2 @@
-require ${PN}_tlk.inc
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+SRC_URI_append = " file://time-limited-kernel.cfg"
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_tlk.inc 
b/meta-tlk/recipes-kernel/linux/linux-yocto_tlk.inc
deleted file mode 100644
index f4c0db3..000
--- a/meta-tlk/recipes-kernel/linux/linux-yocto_tlk.inc
+++ /dev/null
@@ -1,2 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/linux-yocto:"
-SRC_URI_append = " file://time-limited-kernel.cfg"


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

Re: [meta-intel] [PATCH] README: Update information for pyro release

[Cal Sullivan]

Woops, + the real Saul.

---
Cal

On 05/18/2017 01:34 PM, California Sullivan wrote:

Updates several sections that contained outdated information, and adds
a new "Benefits of meta-intel" section.

Signed-off-by: California Sullivan 
---
  README | 149 +++--
  1 file changed, 81 insertions(+), 68 deletions(-)

diff --git a/README b/README
index 777c66c..ad75714 100644
--- a/README
+++ b/README
@@ -21,15 +21,11 @@ Dependencies
  This layer depends on:
  
URI: git://git.openembedded.org/bitbake

-  branch: master
+  branch: 1.34
  
URI: git://git.openembedded.org/openembedded-core

layers: meta
-  branch: master
-
-  URI: git://git.yoctoproject.org/meta-intel
-  layers: intel
-  branch: master
+  branch: pyro
  
  
  Table of Contents

@@ -41,6 +37,7 @@ Table of Contents
   b. Booting the intel-common BSP images
   c. Booting the intel-quark BSP image on a Galileo board
III. Technical Miscellany
+ Benefits of using meta-intel
   The intel-common kernel package architecture
   Intel-specific machine features
IV. Tested Hardware
@@ -149,7 +146,7 @@ You should then be able to build an image as such:
$ source oe-init-build-env
$ bitbake core-image-sato
  
-At the end of a successful build, you should have a live image that

+At the end of a successful build, you should have an image that
  you can boot from a USB flash drive (see instructions on how to do
  that below, in the section 'Booting the intel-common BSP images').
  
@@ -176,12 +173,11 @@ The BSP /binary directory or build contains bootable live images,

  which can be used to directly boot Yocto off of a USB flash drive.
  
  Under Linux, insert a USB flash drive.  Assuming the USB flash drive

-takes device /dev/sdf, use dd to copy the live image to it.  For
-example:
+takes device /dev/sdf, use dd to copy the image to it. For example:
  
-# dd if=core-image-sato-intel-corei7-64.hddimg of=/dev/sdf

-# sync
-# eject /dev/sdf
+$ dd if=core-image-sato-intel-corei7-64.wic of=/dev/sdf
+$ sync
+$ eject /dev/sdf
  
  This should give you a bootable USB flash device.  Insert the device

  into a bootable USB socket on the target, and power on.  This should
@@ -200,7 +196,7 @@ If you find you're getting corrupt images on the USB (it 
doesn't show
  the syslinux boot: prompt, or the boot: prompt contains strange
  characters), try doing this first:
  
-# dd if=/dev/zero of=/dev/sdf bs=1M count=512

+$ dd if=/dev/zero of=/dev/sdf bs=1M count=512
  
  c. Booting the intel-quark BSP image on a Galileo board

  ---
@@ -212,49 +208,31 @@ find the bootable image in the 
build/tmp/deploy/images/xxx directory,
  where again 'xxx' refers to the machine name used in the build.
  
  The Galileo board can boot off of either an SD card or USB storage

-media that has a special disk layout.  The 'wic' tool can be used to
+media that has a special disk layout. The 'wic' tool can be used to
  create directly bootable images for either of the two formats via the
-following steps.
-
-If you haven't already, you need to build parted-native. (You will get
-an error message when running the wic script if you haven't.)
-
-$ bitbake parted-native
-
-Use the wic script to create an SD card image:
-
-$ wic list images
-   galileodisk-sdCreate an Galileo Gen 1/2 disk image (SD card)
-   galileodisk-usb   Create an Galileo Gen 1/2 disk image (USB Storage)
-   mkgummidisk   Create an EFI disk image
+following steps. As of meta-intel 6.0-morty-2.2 or newer, wic images are
+created automatically during build time, and the manual use of wic is
+not necessary. By default, the galileodisk-sd wic kickstart file is used,
+which targets SD cards. This can be changed by setting the WKS_FILE to
+something else in local.conf, such as the following:
  
-Assuming you want to boot the 'core-image-minimal' image for SD card media:

+WKS_FILE = “galileodisk-usb”
  
- $ wic create galileodisk-sd -e core-image-minimal

+If your build is successful, a .wic image will be created in the usual
+deploy directory. Write this image to an SD card:
  
-If successful, the wic script generates the image and prints its location:

+$ sudo dd if=/path/to/image/image-name.wic of=/dev/your_sd_dev
+$ sync
+$ sudo eject /dev/your_sd_dev
  
-   Info: The new image(s) can be found here:

- /var/tmp/wic/build/galileodisk-sd-201604211444-mmcblk0.direct
-   ...
+Insert the SD card into the Galileo and power on.
  
-Write the output image to an SD Card

-
- $ sudo dd if=/path/to/image/galileodisk-sd-*-mmcblk0.direct 
of=/dev/your_sd_dev
-
-Insert the SD Card into the reference platform and power on.
-
-To create a direct-boot image for USB storage media, simply specify
-galileodisk-usb instead of galileodisk-sd in the "wic create ..."
-command, then write the output image to USB st

Re: [meta-intel] [PATCH RFC/RFT] systemd-boot: Add patch to systemd boot stub to fix kernel command line

[Cal Sullivan]

On 04/13/2017 03:29 AM, Patrick Ohly wrote:

On Wed, 2017-04-12 at 17:35 -0700, California Sullivan wrote:

+From 726a1722d30376d2e30561854809edfb05e34047 Mon Sep 17 00:00:00
2001
+From: California Sullivan 
+Date: Wed, 12 Apr 2017 11:10:52 -0700
+Subject: [PATCH] boot: efi: stub: append LoadOptions to command line
instead
+ of replace
+
+Upstream-status: Inappropriate

Why is this inappropriate for upstream? Developers using the upstream
code might have exactly the same problems, so perhaps it is better to
change the upstream default, or at least make it configurable there?



Well, this is a fairly significant change in functionality. There may be 
people that the current upstream functionality is correct for, or what 
they want, that I don't know about.


Now, reading some of the horror stories of this variable, its definitely 
not correct for many, but neither would my implementation.


Here is fun read that Mikko linked me: 
https://github.com/rhinstaller/shim/blob/master/shim.c#L2362


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

Re: [meta-intel] [PATCH] Include recommended packges for all Intel machines

[Cal Sullivan]

On 03/21/2017 02:39 AM, Jussi Laako wrote:

On 21.03.2017 01:59, Cal Sullivan wrote:

The addition of kernel-modules is going to greatly increase the size of
-minimal images for intel-corei7-64 and intel-core2-32, as these
configurations build a lot of modules. I think it would be best to leave
this one in only intel-quark.


On the other hand, then lot of hardware won't work, because drivers 
are built as modules... Pretty much only boot-critical drivers should 
be built into the kernel. I find it especially strange if we have 
linux-firmware installed but not modules, because most of the 
firmwares are used by modules (WiFi drivers, etc). So if 
kernel-modules is removed then also linux-firmware should be removed, 
that is another large package and not boot-critical.


IMO, there are better places to shave off size of minimal images than 
cutting out hardware support.


Your mention of linux-firmware made me realize that I was incorrect with 
my earlier statement. MACHINE_EXTRA_RRECOMMENDS does not effect 
core-image-minimal, see here: 
http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#var-MACHINE_EXTRA_RRECOMMENDS


My apologies! In that case, this looks fine to me.

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

Re: [meta-intel] [PATCH] Include recommended packges for all Intel machines

[Cal Sullivan]

Hi Jussi,

On 03/20/2017 06:08 AM, Jussi Laako wrote:

Moves common MACHINE_EXTRA_RRECOMMENDS to a common include file and
add thermald to MACHINE_EXTRA_RRECOMMENDS.

Signed-off-by: Jussi Laako 
---
  conf/machine/include/meta-intel.inc | 3 +++
  conf/machine/intel-core2-32.conf| 2 --
  conf/machine/intel-corei7-64.conf   | 2 +-
  conf/machine/intel-quark.conf   | 2 --
  4 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/conf/machine/include/meta-intel.inc 
b/conf/machine/include/meta-intel.inc
index 04bd553..38d856f 100644
--- a/conf/machine/include/meta-intel.inc
+++ b/conf/machine/include/meta-intel.inc
@@ -29,6 +29,9 @@ XSERVER_X86_ASPEED_AST = "xf86-video-ast \
  # include the user space intel microcode loading support in the generated 
images.
  MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = 
"${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', ' intel-microcode', '', 
d)}"
  
+# recommended extra packages common to all intel machines

+MACHINE_EXTRA_RRECOMMENDS_append = " kernel-modules linux-firmware thermald"
+
The addition of kernel-modules is going to greatly increase the size of 
-minimal images for intel-corei7-64 and intel-core2-32, as these 
configurations build a lot of modules. I think it would be best to leave 
this one in only intel-quark.


Alejandro,
Do you happen to know if kernel-modules is necessary for intel-quark? It 
would be nice to be able to remove that completely.


---
Cal


  # for the early boot time kernel microcode loading support,
  # merge the microcode data in the final initrd image.
  INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', 
'${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"
diff --git a/conf/machine/intel-core2-32.conf b/conf/machine/intel-core2-32.conf
index c5cfb9c..c15f72b 100644
--- a/conf/machine/intel-core2-32.conf
+++ b/conf/machine/intel-core2-32.conf
@@ -14,8 +14,6 @@ MACHINE_FEATURES += "intel-ucode"
  
  MACHINE_HWCODECS ?= "va-intel gstreamer1.0-vaapi"
  
-MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"

-
  MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "gma500-gfx-check"
  
  XSERVER ?= "${XSERVER_X86_BASE} \

diff --git a/conf/machine/intel-corei7-64.conf 
b/conf/machine/intel-corei7-64.conf
index 43e7c1a..1e5de49 100644
--- a/conf/machine/intel-corei7-64.conf
+++ b/conf/machine/intel-corei7-64.conf
@@ -14,7 +14,7 @@ MACHINE_FEATURES += "intel-ucode"
  
  MACHINE_HWCODECS ?= "va-intel gstreamer1.0-vaapi"
  
-MACHINE_EXTRA_RRECOMMENDS += "linux-firmware lms8"

+MACHINE_EXTRA_RRECOMMENDS += "lms8"
  
  XSERVER ?= "${XSERVER_X86_BASE} \

  ${XSERVER_X86_EXT} \
diff --git a/conf/machine/intel-quark.conf b/conf/machine/intel-quark.conf
index 6e3bb30..17e8c52 100644
--- a/conf/machine/intel-quark.conf
+++ b/conf/machine/intel-quark.conf
@@ -13,8 +13,6 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS = ""
  MACHINE_FEATURES = "efi usb"
  MACHINE_FEATURES += "intel-ucode"
  
-MACHINE_EXTRA_RRECOMMENDS += "kernel-modules linux-firmware"

-
  SERIAL_CONSOLE = "115200 ttyS1"
  APPEND += "rootwait console=ttyS1,115200 console=tty0"
  


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

Re: [meta-intel] [PATCH 1/3] linux-yocto: Add linux-yocto 4.10 bbappends

[Cal Sullivan]

Thanks for the info. I have sent a v2.

---
Cal

On 03/16/2017 03:22 PM, Alejandro Hernandez wrote:

Hey Cal,

That was copied directly from the recipe that had LTO, which 
apparently we wont be using for >4.4 so we wont be needing that line 
anymore.


Alejandro


On 03/16/2017 02:34 PM, Cal Sullivan wrote:
Alejandro, I'd appreciate a review on the tiny bbappend, as I didn't 
entirely understand the EXTRA_OEMAKE that you added to the 4.9 
recipe, and this is essentially a copy of that.


Thanks,
Cal

On 03/16/2017 01:28 PM, California Sullivan wrote:

Like the 4.9 linux-yocto kernel, we will just float on OE-core's
SRCREVs.

Signed-off-by: California Sullivan 
---
  .../linux/linux-yocto-rt_4.10.bbappend  | 13 
+
  .../linux/linux-yocto-tiny_4.10.bbappend| 19 
+++
  .../recipes-kernel/linux/linux-yocto_4.10.bbappend  | 21 
+

  3 files changed, 53 insertions(+)
  create mode 100644 
common/recipes-kernel/linux/linux-yocto-rt_4.10.bbappend
  create mode 100644 
common/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend
  create mode 100644 
common/recipes-kernel/linux/linux-yocto_4.10.bbappend


diff --git 
a/common/recipes-kernel/linux/linux-yocto-rt_4.10.bbappend 
b/common/recipes-kernel/linux/linux-yocto-rt_4.10.bbappend

new file mode 100644
index 000..9d2e3c0
--- /dev/null
+++ b/common/recipes-kernel/linux/linux-yocto-rt_4.10.bbappend
@@ -0,0 +1,13 @@
+KERNEL_FEATURES_INTEL_COMMON = ""
+
+COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
+KMACHINE_core2-32-intel-common = "intel-core2-32"
+KERNEL_FEATURES_append_core2-32-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON}"

+
+COMPATIBLE_MACHINE_corei7-64-intel-common = "${MACHINE}"
+KMACHINE_corei7-64-intel-common = "intel-corei7-64"
+KERNEL_FEATURES_append_corei7-64-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON}"

+
+COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
+KMACHINE_i586-nlp-32-intel-common = "intel-quark"
+KERNEL_FEATURES_append_i586-nlp-32-intel-common = ""
diff --git 
a/common/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend 
b/common/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend

new file mode 100644
index 000..a9a10ea
--- /dev/null
+++ b/common/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend
@@ -0,0 +1,19 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+EXTRA_OEMAKE = 
"LD=${STAGING_BINDIR_NATIVE}/${HOST_SYS}/${TARGET_PREFIX}ld 
AR=${STAGING_BINDIR_NATIVE}/${HOST_SYS}/${TARGET_PREFIX}gcc-ar"

+
+COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
+COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
+COMPATIBLE_MACHINE_corei7-64-intel-common = "${MACHINE}"
+
+KBRANCH_i586-nlp-32-intel-common = "standard/tiny/base"
+KBRANCH_core2-32-intel-common = "standard/tiny/base"
+KBRANCH_corei7-64-intel-common = "standard/tiny/base"
+
+KMACHINE_i586-nlp-32-intel-common = "intel-quark"
+KMACHINE_core2-32-intel-common = "intel-core2-32"
+KMACHINE_corei7-64-intel-common = "intel-corei7-64"
+
+KERNEL_FEATURES_append_i586-nlp-32-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON} cfg/fs/ext4.scc"
+KERNEL_FEATURES_append_core2-32-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON} cfg/fs/ext4.scc"
+KERNEL_FEATURES_append_corei7-64-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON} cfg/fs/ext4.scc"
diff --git a/common/recipes-kernel/linux/linux-yocto_4.10.bbappend 
b/common/recipes-kernel/linux/linux-yocto_4.10.bbappend

new file mode 100644
index 000..a09fe1a
--- /dev/null
+++ b/common/recipes-kernel/linux/linux-yocto_4.10.bbappend
@@ -0,0 +1,21 @@
+KERNEL_FEATURES_INTEL_COMMON = ""
+
+COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
+KMACHINE_core2-32-intel-common = "intel-core2-32"
+KERNEL_FEATURES_append_core2-32-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON}"

+
+COMPATIBLE_MACHINE_corei7-64-intel-common = "${MACHINE}"
+KMACHINE_corei7-64-intel-common = "intel-corei7-64"
+KERNEL_FEATURES_append_corei7-64-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON}"

+
+COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
+KMACHINE_i586-nlp-32-intel-common = "intel-quark"
+KERNEL_FEATURES_append_i586-nlp-32-intel-common = ""
+
+# For Crystalforest and Romley
+KERNEL_MODULE_AUTOLOAD_append_core2-32-intel-common = " uio"
+KERNEL_MODULE_AUTOLOAD_append_corei7-64-intel-common = " uio"
+
+# For FRI2, NUC
+KERNEL_MODULE_AUTOLOAD_append_core2-32-intel-common = " iwlwifi"
+KERNEL_MODULE_AUTOLOAD_append_corei7-64-intel-common = " iwlwifi"






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

Re: [meta-intel] [PATCH 1/3] linux-yocto: Add linux-yocto 4.10 bbappends

[Cal Sullivan]

Alejandro, I'd appreciate a review on the tiny bbappend, as I didn't 
entirely understand the EXTRA_OEMAKE that you added to the 4.9 recipe, 
and this is essentially a copy of that.


Thanks,
Cal

On 03/16/2017 01:28 PM, California Sullivan wrote:

Like the 4.9 linux-yocto kernel, we will just float on OE-core's
SRCREVs.

Signed-off-by: California Sullivan 
---
  .../linux/linux-yocto-rt_4.10.bbappend  | 13 +
  .../linux/linux-yocto-tiny_4.10.bbappend| 19 +++
  .../recipes-kernel/linux/linux-yocto_4.10.bbappend  | 21 +
  3 files changed, 53 insertions(+)
  create mode 100644 common/recipes-kernel/linux/linux-yocto-rt_4.10.bbappend
  create mode 100644 common/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend
  create mode 100644 common/recipes-kernel/linux/linux-yocto_4.10.bbappend

diff --git a/common/recipes-kernel/linux/linux-yocto-rt_4.10.bbappend 
b/common/recipes-kernel/linux/linux-yocto-rt_4.10.bbappend
new file mode 100644
index 000..9d2e3c0
--- /dev/null
+++ b/common/recipes-kernel/linux/linux-yocto-rt_4.10.bbappend
@@ -0,0 +1,13 @@
+KERNEL_FEATURES_INTEL_COMMON = ""
+
+COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
+KMACHINE_core2-32-intel-common = "intel-core2-32"
+KERNEL_FEATURES_append_core2-32-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON}"
+
+COMPATIBLE_MACHINE_corei7-64-intel-common = "${MACHINE}"
+KMACHINE_corei7-64-intel-common = "intel-corei7-64"
+KERNEL_FEATURES_append_corei7-64-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON}"
+
+COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
+KMACHINE_i586-nlp-32-intel-common = "intel-quark"
+KERNEL_FEATURES_append_i586-nlp-32-intel-common = ""
diff --git a/common/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend 
b/common/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend
new file mode 100644
index 000..a9a10ea
--- /dev/null
+++ b/common/recipes-kernel/linux/linux-yocto-tiny_4.10.bbappend
@@ -0,0 +1,19 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+EXTRA_OEMAKE = "LD=${STAGING_BINDIR_NATIVE}/${HOST_SYS}/${TARGET_PREFIX}ld 
AR=${STAGING_BINDIR_NATIVE}/${HOST_SYS}/${TARGET_PREFIX}gcc-ar"
+
+COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
+COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
+COMPATIBLE_MACHINE_corei7-64-intel-common = "${MACHINE}"
+
+KBRANCH_i586-nlp-32-intel-common = "standard/tiny/base"
+KBRANCH_core2-32-intel-common = "standard/tiny/base"
+KBRANCH_corei7-64-intel-common = "standard/tiny/base"
+
+KMACHINE_i586-nlp-32-intel-common = "intel-quark"
+KMACHINE_core2-32-intel-common = "intel-core2-32"
+KMACHINE_corei7-64-intel-common = "intel-corei7-64"
+
+KERNEL_FEATURES_append_i586-nlp-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON} 
cfg/fs/ext4.scc"
+KERNEL_FEATURES_append_core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON} 
cfg/fs/ext4.scc"
+KERNEL_FEATURES_append_corei7-64-intel-common = "${KERNEL_FEATURES_INTEL_COMMON} 
cfg/fs/ext4.scc"
diff --git a/common/recipes-kernel/linux/linux-yocto_4.10.bbappend 
b/common/recipes-kernel/linux/linux-yocto_4.10.bbappend
new file mode 100644
index 000..a09fe1a
--- /dev/null
+++ b/common/recipes-kernel/linux/linux-yocto_4.10.bbappend
@@ -0,0 +1,21 @@
+KERNEL_FEATURES_INTEL_COMMON = ""
+
+COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
+KMACHINE_core2-32-intel-common = "intel-core2-32"
+KERNEL_FEATURES_append_core2-32-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON}"
+
+COMPATIBLE_MACHINE_corei7-64-intel-common = "${MACHINE}"
+KMACHINE_corei7-64-intel-common = "intel-corei7-64"
+KERNEL_FEATURES_append_corei7-64-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON}"
+
+COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
+KMACHINE_i586-nlp-32-intel-common = "intel-quark"
+KERNEL_FEATURES_append_i586-nlp-32-intel-common = ""
+
+# For Crystalforest and Romley
+KERNEL_MODULE_AUTOLOAD_append_core2-32-intel-common = " uio"
+KERNEL_MODULE_AUTOLOAD_append_corei7-64-intel-common = " uio"
+
+# For FRI2, NUC
+KERNEL_MODULE_AUTOLOAD_append_core2-32-intel-common = " iwlwifi"
+KERNEL_MODULE_AUTOLOAD_append_corei7-64-intel-common = " iwlwifi"


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

Re: [meta-intel] [PATCH 1/8] common/binutils-2.24.51.0.3: New recipe

[Cal Sullivan]

This one really scares me. Old version, removed CVE fixes, and might 
cause compatibility issues with other layers...


Saul?

Thanks,
Cal

On 02/13/2017 01:52 PM, Alejandro Hernandez wrote:

This is severely hacked version of the fido binutils recipe, which is
the latest binutils 2.24 recipe that we have to start with.

Instead of using the standard gnu binutils, however, for kernel LTO,
(which is the only reason we need this), we need to use the 'Linux
binutils', which is a different tarball/branch.

The problem is that there are various fixes needed for this version of
binutils to work with gcc 6.2, and many of the patches in 2.24, such
as the CVE patches, don't apply at build-time and so have been
commented out.

We should really be using the normal standard 2.7 binutils (using of
course the linux binutils branch) but that currently produces internal
errors during the kernel build.

For now, this works, and allows us to produce a working LTO-enabled
kernel.

Signed-off-by: Tom Zanussi


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

Re: [meta-intel] [PATCH] intel-quark: Add intel-quark-preempt-rt bsp configuration

[Cal Sullivan]

Looks fine to me, but should go to the linux-yo...@yoctoproject.org 
mailing list.


Thanks,
Cal

On 02/02/2017 09:28 AM, Jan Kiszka wrote:

From: Christian Storm 

While there are intel-quark configurations for the KTYPEs standard and
tiny in bsp/intel-common, there's none for the preempt-rt KTYPE.
Trying to build preempt-rt enabled kernels such as linux-yocto-rt for
intel-quark yields a .config having a potentially misconfigured
architecture. More importantly, however, preempt-rt related CONFIG
options are not enabled. Hence, a build of, e.g., linux-yocto-rt, does
not result in a preempt-rt enabled kernel.

This patch qualifies to be (back)ported to other branches than master.

Signed-off-by: Christian Storm 
Signed-off-by: Jan Kiszka 
---

In particular, we would be interested in a 4.4 application as that is
currently in use by meta-iot2000.

  bsp/intel-common/intel-quark-preempt-rt.scc | 20 
  1 file changed, 20 insertions(+)
  create mode 100644 bsp/intel-common/intel-quark-preempt-rt.scc

diff --git a/bsp/intel-common/intel-quark-preempt-rt.scc 
b/bsp/intel-common/intel-quark-preempt-rt.scc
new file mode 100644
index ..8a00fae4
--- /dev/null
+++ b/bsp/intel-common/intel-quark-preempt-rt.scc
@@ -0,0 +1,20 @@
+# intel-quark-preempt-rt.scc
+#
+# preempt-rt ktype for 32 bit Quark / X1000 CPUs
+#
+
+define KMACHINE intel-quark
+define KARCH i386
+define KTYPE preempt-rt
+
+include ktypes/preempt-rt/preempt-rt.scc
+branch intel
+
+# Enable booting from USB for Standard Kernel Image
+include cfg/usb-mass-storage.scc
+include cfg/boot-live.scc
+
+include intel-common.scc
+include features/power/intel.scc
+include intel-common-drivers-32.scc
+include intel-quark.scc


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

Re: [meta-intel] [PATCH 1/2] systemd-boot: use RMC database in EFI stub

[Cal Sullivan]

Thanks for reviewing these. Since they look fine to you and my build 
went well I went ahead and merged them.


Thanks,
Cal

On 02/05/2017 08:51 PM, Jianxun Zhang wrote:

I noticed there are several RMC patches in mailing list and should review them 
tomorrow. (Just returned from a vacation)

Refer to my initial comment for Saul’s. Appreciate Mikko going through the 
following up when I was off.



On Feb 2, 2017, at 12:46 PM, Ylinen, Mikko  wrote:

Hi,

On Fri, Jan 27, 2017 at 6:05 PM, Wold, Saul  wrote:
On Fri, 2017-01-27 at 15:36 +0200, Mikko Ylinen wrote:

systemd-boot's EFI stub can be built in an EFI executable
with the kernel, cmdline, and initrd.

This commit enables the EFI stub code to use the RMC database
and appends the board specific cmdline (KBOOTPARAM) to the
built-in cmdline.


If we are going to expose the KBOOTPARAM this way, shouldn't that be
done inside of RMC proper and a getter type of API to provide
KBOOTPARAM directly?

Assuming this thoughts is to the upstream RMC project.

I have to stress my opinion. RMC is designed as a _generic_ file-based 
centralized solution so that any software (EFI and user space) could get its 
service within just 1~2 API calls.

KBOOTPARAM and how to parse or use its content is too client-specific. (Even 
the name “KBOOMPARAM” is derived from kernel doc, nothing about RMC).

Packing client-specifc stuff in RMC core could damage the scalability in the 
future. Say, how could we support bootloaders that need different behavior of 
KBOOTPARAM in RMC?

I understand people want to get rid of another copy of this logic, and am 
thinking maybe we should have a new file/API in systemd-boot as the shim (?)

Thanks




Makes a lot of sense to me. However, until that API is in place, I'd suggest
we use what I'm proposing for the stub here (that's the same approach used with
the full bootloader as well).

Just want to point out the a small difference between main bootloader and stub 
at this point. the main is implemented with single-action APIs for a 
potentially better performance when query multiple files. The stub uses 
double-action API to simplify the code because it only read one file so far.

-- Mikko
--
___
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] linux-yocto/4.4: Fix wrong rt SRCREV for 4.4 - for real

[Cal Sullivan]

On 01/19/2017 03:16 AM, Jan Kiszka wrote:

d86d58a99dd4 didn't fix the issue it wanted to address but rather
referred to the corresponding commit of standard/tiny/intel/base instead
of standard/preempt-rt/intel/base. A local workaround for the original
meta-intel issue papered over this during testing. Fix it for real.

Signed-off-by: Jan Kiszka 
---

Argh, now I messed it up. I wonder if you could enable some Q&A build
for meta-intel's stable branches (or for all, if that doesn't exist
yet). It's too easy to get things wrong...
Newer versions will catch the original problem (wrong SRCREV for the 
linux version), but its on me that I merged your patch without doing a 
build with it first. My apologies.

---
Cal



BTW, there are more issues with -rt and Quark: another build fix will
follow, and I'm currently discussing a patch (enable MSI for SPI) that
also acts as workaround for some issue with shared interrupts with
Linux upstream. We may discuss a backport to yocto 4.4 and 4.8
afterwards.

  common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend 
b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
index 64cf783..5b9b98b 100644
--- a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
@@ -2,7 +2,7 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
  
  LINUX_VERSION_INTEL_COMMON = "4.4.26"

  SRCREV_META_INTEL_COMMON = "870134f4bfa6208d6e5339e065486be3b6e693a5"
-SRCREV_MACHINE_INTEL_COMMON = "4eb72141aa7c3b626a7fc42ae8da6f8b29e43a2c"
+SRCREV_MACHINE_INTEL_COMMON = "c5851eb141c2c64b0f6d453c45c4200dfede1a79"
  
  KBRANCH_INTEL_COMMON = "standard/preempt-rt/intel/base"
  


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

Re: [meta-intel] [PATCH] meta-intel: enable qemu and select more suitable virtual machine options

[Cal Sullivan]

On 01/12/2017 06:19 AM, Patrick Ohly wrote:

Although the machines definitions in meta-intel are meant to target
real hardware, begin able to start the resulting images under qemu is
nevertheless useful for testing.

Doing that via runqemu depends on a per-image runqemu.conf that
describes how to run qemu for the image. Ineriting qemuboot.bbclass in
image recipes with QB_ variables set for the current architecture via
overrides creates that file.

The new qemuboot-intel.inc was copied from OE-core's qemuboot-x86.inc
and adapted to the three common machines in meta-intel:

$ diff ../openembedded-core/meta/conf/machine/include/qemuboot-x86.inc 
conf/machine/include/qemuboot-intel.inc
3,5c3,5
< QB_SYSTEM_NAME_x86 = "qemu-system-i386"
< QB_CPU_x86 = "-cpu qemu32"
< QB_CPU_KVM_x86 = "-cpu kvm32"
---

QB_SYSTEM_NAME_intel-core2-32 = "qemu-system-i386"
QB_CPU_intel-core2-32 = "-cpu coreduo"
QB_CPU_KVM_intel-core2-32 = "-cpu kvm32"

7,9c7,13
< QB_SYSTEM_NAME_x86-64 = "qemu-system-x86_64"
< QB_CPU_x86-64 = "-cpu core2duo"
< QB_CPU_KVM_x86-64 = "-cpu kvm64"
---

QB_SYSTEM_NAME_intel-corei7-64 = "qemu-system-x86_64"
QB_CPU_intel-corei7-64 = "-cpu Nehalem"
QB_CPU_KVM_intel-corei7-64 = "-cpu kvm64"

QB_SYSTEM_NAME_intel-quark = "qemu-system-i386"
QB_CPU_intel-quark = "-cpu coreduo"
QB_CPU_KVM_intel-quark = "-cpu kvm32"

intel-core2-32 and intel-corei7-64 work (tested with an Ostro OS
derivative with OVMF as firmware), whereas intel-quark hangs while
showing the OVMF/TianoCore logo.

In all three cases there's a (harmless?) warning:
warning: TCG doesn't support requested feature: CPUID.01H:EDX.vme [bit 1]

Including qemu.inc (from OE-core) ensures that qemu gets built when
building an image.

Signed-off-by: Patrick Ohly 
---
  conf/machine/include/meta-intel.inc |  6 ++
  conf/machine/include/qemuboot-intel.inc | 20 
  2 files changed, 26 insertions(+)
  create mode 100644 conf/machine/include/qemuboot-intel.inc

diff --git a/conf/machine/include/meta-intel.inc 
b/conf/machine/include/meta-intel.inc
index fd0a792..437fd38 100644
--- a/conf/machine/include/meta-intel.inc
+++ b/conf/machine/include/meta-intel.inc
@@ -36,3 +36,9 @@ EFI_PROVIDER ?= "rmc-boot"
  
  # Add general MACHINEOVERRIDE for meta-intel

  MACHINEOVERRIDES =. "intel-x86-common:"
+
+# All machine flavors may (or may not) run on qemu...
+require conf/machine/include/qemuboot-intel.inc
+
+# Ensure that the extra tools needed by qemu are built when building images.
+require conf/machine/include/qemu.inc
diff --git a/conf/machine/include/qemuboot-intel.inc 
b/conf/machine/include/qemuboot-intel.inc
new file mode 100644
index 000..82a72ac
--- /dev/null
+++ b/conf/machine/include/qemuboot-intel.inc
@@ -0,0 +1,20 @@
+# For runqemu
+IMAGE_CLASSES += "qemuboot"
+QB_SYSTEM_NAME_intel-core2-32 = "qemu-system-i386"
+QB_CPU_intel-core2-32 = "-cpu coreduo"
+QB_CPU_KVM_intel-core2-32 = "-cpu kvm32"
+
+QB_SYSTEM_NAME_intel-corei7-64 = "qemu-system-x86_64"
+QB_CPU_intel-corei7-64 = "-cpu Nehalem"
+QB_CPU_KVM_intel-corei7-64 = "-cpu kvm64"
+
+QB_SYSTEM_NAME_intel-quark = "qemu-system-i386"
+QB_CPU_intel-quark = "-cpu coreduo"
+QB_CPU_KVM_intel-quark = "-cpu kvm32"
+
+QB_AUDIO_DRV = "alsa"
+QB_AUDIO_OPT = "-soundhw ac97,es1370"
+QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 
uvesafb.task_timeout=-1"
+# Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
+QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device 
virtio-rng-pci"

Our kernel's .config has the following, will this cause any issues?

#
# Virtio drivers
#
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_MMIO is not set

Thanks,
Cal


+QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::-:22"


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

Re: [meta-intel] [PATCH] linux-yocto/4.4: Fix wrong rt SRCREV for 4.4

[Cal Sullivan]

Its been merged. Apologies for the delay.

---
Cal

On 01/11/2017 11:12 PM, Jan Kiszka wrote:

On 2017-01-09 22:17, Cal Sullivan wrote:

I'm not sure how I managed to do that. Thanks for the patch.

When will it be merged? I'd like to avoid starting to carry a workaround
in our layer (meta-iot2000).

Thanks,
Jan


---
Cal

On 01/09/2017 01:10 PM, Jan Kiszka wrote:

This one refers to the merge of 4.4.26. Mistake of 371461eae450.

Signed-off-by: Jan Kiszka 
---
   common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
index ebb545d..64cf783 100644
--- a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
@@ -2,7 +2,7 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 LINUX_VERSION_INTEL_COMMON = "4.4.26"
   SRCREV_META_INTEL_COMMON = "870134f4bfa6208d6e5339e065486be3b6e693a5"
-SRCREV_MACHINE_INTEL_COMMON = "13852755ecbf491848afbe40e66fc152bc70915b"
+SRCREV_MACHINE_INTEL_COMMON = "4eb72141aa7c3b626a7fc42ae8da6f8b29e43a2c"
 KBRANCH_INTEL_COMMON = "standard/preempt-rt/intel/base"
   


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

Re: [meta-intel] [PATCH] linux-yocto/4.4: Fix wrong rt SRCREV for 4.4

[Cal Sullivan]

I'm not sure how I managed to do that. Thanks for the patch.

---
Cal

On 01/09/2017 01:10 PM, Jan Kiszka wrote:

This one refers to the merge of 4.4.26. Mistake of 371461eae450.

Signed-off-by: Jan Kiszka 
---
  common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend 
b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
index ebb545d..64cf783 100644
--- a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
@@ -2,7 +2,7 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
  
  LINUX_VERSION_INTEL_COMMON = "4.4.26"

  SRCREV_META_INTEL_COMMON = "870134f4bfa6208d6e5339e065486be3b6e693a5"
-SRCREV_MACHINE_INTEL_COMMON = "13852755ecbf491848afbe40e66fc152bc70915b"
+SRCREV_MACHINE_INTEL_COMMON = "4eb72141aa7c3b626a7fc42ae8da6f8b29e43a2c"
  
  KBRANCH_INTEL_COMMON = "standard/preempt-rt/intel/base"
  


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

Re: [meta-intel] [PATCH] rmc: Extend usages of RMC_BOARD_DATA_DIRS to specify board data

[Cal Sullivan]

Looks good and makes sense. Merged.

---
Cal

On 01/05/2017 04:15 PM, Jianxun Zhang wrote:

Use the variable RMC_BOARD_DATA_DIRS, to disable, append to, or
override the default board data in meta-intel with boards' data
provided by users.

Ideally, users should get the updated database in the new built
image after an incremental build.

Examples of RMC database output (db):

RMC_BOARD_DATA_DIRS  = "" (disable db generation)
RMC_BOARD_DATA_DIRS_append = " top_dir" (db of defaults & user's)
RMC_BOARD_DATA_DIRS = "top_dir" (db for user's , no defaults)
RMC_BOARD_DATA_DIRS  = " " (same as "")

Signed-off-by: Jianxun Zhang 
---
  classes/rmc-boot.bbclass |  6 +-
  common/recipes-bsp/rmc/rmc-db.bb |  3 ++-
  documentation/rmc/README | 41 
  3 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/classes/rmc-boot.bbclass b/classes/rmc-boot.bbclass
index a1f2093..37c3e30 100644
--- a/classes/rmc-boot.bbclass
+++ b/classes/rmc-boot.bbclass
@@ -9,5 +9,9 @@ inherit ${RMC_BOOTLOADER}
  do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"
  
  efi_populate_append() {

-install -m 0400 ${DEPLOY_DIR_IMAGE}/rmc.db ${DEST}/rmc.db
+   if [ -f ${DEPLOY_DIR_IMAGE}/rmc.db ]; then
+   install -m 0400 ${DEPLOY_DIR_IMAGE}/rmc.db ${DEST}/rmc.db
+   else
+   rm -f ${DEST}/rmc.db
+   fi
  }
diff --git a/common/recipes-bsp/rmc/rmc-db.bb b/common/recipes-bsp/rmc/rmc-db.bb
index 14553af..99565fd 100644
--- a/common/recipes-bsp/rmc/rmc-db.bb
+++ b/common/recipes-bsp/rmc/rmc-db.bb
@@ -14,7 +14,7 @@ S = "${WORKDIR}"
  
  inherit rmc-db
  
-RMC_BOARD_DATA_DIRS_append := " ${THISDIR}/boards/"

+RMC_BOARD_DATA_DIRS ?= "${THISDIR}/boards/"
  RMC_DB_DIR = "${WORKDIR}/db"
  
  # Let sstate be aware of change in any added board directories

@@ -41,6 +41,7 @@ do_deploy () {
if [ -f ${RMC_DB_DIR}/rmc.db ]; then
install -m 0400 ${RMC_DB_DIR}/rmc.db ${DEPLOYDIR}
else
+   rm -f ${DEPLOYDIR}/rmc.db
echo "Warning: no RMC central database found, skip deployment."
fi
  }
diff --git a/documentation/rmc/README b/documentation/rmc/README
index dbee6b6..eaa763e 100644
--- a/documentation/rmc/README
+++ b/documentation/rmc/README
@@ -82,15 +82,31 @@ following this example, so that RMC recipes can pick up 
them correctly in build.
|- ...more files
  
  Note 0:

-To add your boards into RMC feature, simply put this line in your
-rmc-db.bbappend:
+Developers are expected to use variable RMC_BOARD_DATA_DIRS to specify data of
+boards packed into RMC database file generated in a build. The default value of
+the variable in meta-intel specifies a group of boards. They work as examples
+and necessary quirks for these boards to function properly. Developers can
+override, append to the default boards with data of their own boards in the
+database file, or even disable the generation of the database file.
  
-RMC_BOARD_DATA_DIRS_append := " ${THISDIR}/my_top_dir"

+For example, in your local.conf file:
  
-RMC db recipe takes all top directories specified in RMC_BOARD_DATA_DIRS to

-construct and deploy a central RMC database inside image. The bbclass of the
-bare RMC project also provide function for other components to construct their
-own RMC database file. Please refer to rmc-db.bbclass for more information.
+This line adds your boards along with the default boards into RMC database 
file,
+assuming you have a directory named "rmc" which has a subdirectory for each
+board:
+
+RMC_BOARD_DATA_DIRS_append = " /path_of/rmc"
+
+This line directs RMC to pack data of your boards only, without data of the
+default boards in meta-intel:
+
+RMC_BOARD_DATA_DIRS = "/path_of/rmc"
+
+And this line disables database generation:
+
+RMC_BOARD_DATA_DIRS = ""
+
+Please also refer to the "Example 1" in this document.
  
  Subdirectory is not supported in a board's directory.
  
@@ -175,15 +191,8 @@ bootloader please overwrite the RMC_BOOTLOADER variable in your local.conf
  
  Note:

  Image could be still bootable if you only have either of two lines, but RMC
-feature won't be fully functional.
-
-To install only the RMC client with the systemd-boot bootloader without
-including a default RMC database file, add the following lines to your
-local.conf:
-
-EFI_PROVIDER = "systemd-boot"
-IMAGE_INSTALL_append = " rmc"
-
+feature could not be fully functional, depending on the availability of the
+database file, installer and the rmc tool.
  
  Examples

  



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

Re: [meta-intel] [yocto] [meta-inte][rmc][PATCH v2 1/1] rmc: add support for alternative EFI bootloaders

[Cal Sullivan]

On 12/15/2016 10:23 AM, Todor Minchev wrote:

On Thu, 2016-12-15 at 10:09 -0800, Cal Sullivan wrote:

On 12/13/2016 04:50 PM, Todor Minchev wrote:

On Tue, 2016-12-13 at 16:22 -0800, Jianxun Zhang wrote:

On Dec 13, 2016, at 2:56 PM, Todor Minchev  wrote:

RMC was previously configured to work only with the systemd-
boot EFI
bootloader. With this commit we can specify alternative
bootloaders by
setting the RMC_BOOTLOADER variable in local.conf. If
RMC_BOOTLOADER is
not set systemd-boot will be used by default.

Signed-off-by: Todor Minchev 
---
Remove references to grub-efi and gummiboot from V1.

classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} |  5
+++--
conf/machine/include/meta-intel.inc|  2 +-
documentation/rmc/README   | 16
+---
3 files changed, 17 insertions(+), 6 deletions(-)
rename classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass}
(73%)

diff --git a/classes/rmc-systemd-boot.bbclass b/classes/rmc-
boot.bbclass
similarity index 73%
rename from classes/rmc-systemd-boot.bbclass
rename to classes/rmc-boot.bbclass
index ad2cf10..a1f2093 100644
--- a/classes/rmc-systemd-boot.bbclass
+++ b/classes/rmc-boot.bbclass
@@ -1,9 +1,10 @@
-# rmc-systemd-boot bbclass
+# rmc-boot bbclass
# Deploy central RMC database file to ESP

IMAGE_INSTALL_append = " rmc"
+RMC_BOOTLOADER ?= "systemd-boot”

Maybe this is what we could have now without bothering OE. It is
better than the corrent code at the cost of another variable to
user. I hope in the future we could get rid of  the dependency to
EFI_PROVIDER (e.g. bz10084).

Also refer to my comment for the document change at the below.

-inherit systemd-boot
+inherit ${RMC_BOOTLOADER}

do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"

diff --git a/conf/machine/include/meta-intel.inc
b/conf/machine/include/meta-intel.inc
index c7555ce..fd0a792 100644
--- a/conf/machine/include/meta-intel.inc
+++ b/conf/machine/include/meta-intel.inc
@@ -32,7 +32,7 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = "${
@bb.utils.contains('MACHINE_FEATURE
# merge the microcode data in the final initrd image.
INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES',
'intel-ucode', '${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"

-EFI_PROVIDER ?= "rmc-systemd-boot"
+EFI_PROVIDER ?= "rmc-boot"

# Add general MACHINEOVERRIDE for meta-intel
MACHINEOVERRIDES =. "intel-x86-common:"
diff --git a/documentation/rmc/README
b/documentation/rmc/README
index 2427ffd..dbee6b6 100644
--- a/documentation/rmc/README
+++ b/documentation/rmc/README
@@ -165,14 +165,24 @@ steps still can override results from
this hook for boot entries and KBOOTPARAM.

Enable RMC Feature
-
---
-To Enable RMC feature in build, add the below lines in a conf
file:
+To enable the RMC feature please add the following variables
to your local.conf.
+
DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"
+
+The default EFI bootloader used with RMC is systemd-boot. To
change the default
+bootloader please overwrite the RMC_BOOTLOADER variable in
your local.conf

Note:
Image could be still bootable if you only have either of two
lines, but RMC
feature won't be fully functional.

+To install only the RMC client with the systemd-boot
bootloader without
+including a default RMC database file, add the following lines
to your
+local.conf:
+
+EFI_PROVIDER = "systemd-boot"
+IMAGE_INSTALL_append = " rmc”

I think this use case could confuse for user without much
benefit. And actually they still can set EFI_PROVIDER to any
available efi bootloaders to get this effect as long as it is not
“rmc-boot”, right?
Maybe we should just say “you won’t get rmc database deployed if
you set EFI_PROVIDER to any values not rmc-boot."

Yes, this can be another way to phrase this.

Is there going to be a v3 or is it sufficient as-is?

This is OK for now. I will reword the README after we add full RMC
support to grub-efi.

Great, thanks. I will merge it shortly along with Ross' changes.

  

Thanks,
Cal



Examples
@@ -190,7 +200,7 @@ EXAMPLE 1: Support a new board type:
(1) enable the feature and do a build to get a live-boot image
by adding these
  lines in conf/local.conf:
  DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"

(2) flash the image to a USB stick and boot it on your board



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

Re: [meta-intel] [yocto] [meta-inte][rmc][PATCH v2 1/1] rmc: add support for alternative EFI bootloaders

[Cal Sullivan]

On 12/13/2016 04:50 PM, Todor Minchev wrote:

On Tue, 2016-12-13 at 16:22 -0800, Jianxun Zhang wrote:

On Dec 13, 2016, at 2:56 PM, Todor Minchev  
wrote:

RMC was previously configured to work only with the systemd-boot EFI
bootloader. With this commit we can specify alternative bootloaders by
setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is
not set systemd-boot will be used by default.

Signed-off-by: Todor Minchev 
---
Remove references to grub-efi and gummiboot from V1.

classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} |  5 +++--
conf/machine/include/meta-intel.inc|  2 +-
documentation/rmc/README   | 16 +---
3 files changed, 17 insertions(+), 6 deletions(-)
rename classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} (73%)

diff --git a/classes/rmc-systemd-boot.bbclass b/classes/rmc-boot.bbclass
similarity index 73%
rename from classes/rmc-systemd-boot.bbclass
rename to classes/rmc-boot.bbclass
index ad2cf10..a1f2093 100644
--- a/classes/rmc-systemd-boot.bbclass
+++ b/classes/rmc-boot.bbclass
@@ -1,9 +1,10 @@
-# rmc-systemd-boot bbclass
+# rmc-boot bbclass
# Deploy central RMC database file to ESP

IMAGE_INSTALL_append = " rmc"
+RMC_BOOTLOADER ?= "systemd-boot”

Maybe this is what we could have now without bothering OE. It is better than 
the corrent code at the cost of another variable to user. I hope in the future 
we could get rid of  the dependency to EFI_PROVIDER (e.g. bz10084).

Also refer to my comment for the document change at the below.

-inherit systemd-boot
+inherit ${RMC_BOOTLOADER}

do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"

diff --git a/conf/machine/include/meta-intel.inc 
b/conf/machine/include/meta-intel.inc
index c7555ce..fd0a792 100644
--- a/conf/machine/include/meta-intel.inc
+++ b/conf/machine/include/meta-intel.inc
@@ -32,7 +32,7 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = 
"${@bb.utils.contains('MACHINE_FEATURE
# merge the microcode data in the final initrd image.
INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', 
'${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"

-EFI_PROVIDER ?= "rmc-systemd-boot"
+EFI_PROVIDER ?= "rmc-boot"

# Add general MACHINEOVERRIDE for meta-intel
MACHINEOVERRIDES =. "intel-x86-common:"
diff --git a/documentation/rmc/README b/documentation/rmc/README
index 2427ffd..dbee6b6 100644
--- a/documentation/rmc/README
+++ b/documentation/rmc/README
@@ -165,14 +165,24 @@ steps still can override results from this hook for boot 
entries and KBOOTPARAM.

Enable RMC Feature

-To Enable RMC feature in build, add the below lines in a conf file:
+To enable the RMC feature please add the following variables to your 
local.conf.
+
DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"
+
+The default EFI bootloader used with RMC is systemd-boot. To change the default
+bootloader please overwrite the RMC_BOOTLOADER variable in your local.conf

Note:
Image could be still bootable if you only have either of two lines, but RMC
feature won't be fully functional.

+To install only the RMC client with the systemd-boot bootloader without
+including a default RMC database file, add the following lines to your
+local.conf:
+
+EFI_PROVIDER = "systemd-boot"
+IMAGE_INSTALL_append = " rmc”

I think this use case could confuse for user without much benefit. And actually 
they still can set EFI_PROVIDER to any available efi bootloaders to get this 
effect as long as it is not “rmc-boot”, right?
Maybe we should just say “you won’t get rmc database deployed if you set 
EFI_PROVIDER to any values not rmc-boot."

Yes, this can be another way to phrase this.

Is there going to be a v3 or is it sufficient as-is?

Thanks,
Cal



Examples
@@ -190,7 +200,7 @@ EXAMPLE 1: Support a new board type:
(1) enable the feature and do a build to get a live-boot image by adding these
 lines in conf/local.conf:
 DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"

(2) flash the image to a USB stick and boot it on your board

--
2.11.0





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

Re: [meta-intel] [yocto] [meta-inte][rmc][PATCH v2 1/1] rmc: add support for alternative EFI bootloaders

[Cal Sullivan]

I like where this is heading but does RMC function with bootloaders 
besides systemd-boot yet?
A quick boot test with this patch and RMC_BOOTLOADER = "grub-efi" seems 
to give me vanilla grub-efi.


Thanks,
Cal

On 12/13/2016 04:50 PM, Todor Minchev wrote:

On Tue, 2016-12-13 at 16:22 -0800, Jianxun Zhang wrote:

On Dec 13, 2016, at 2:56 PM, Todor Minchev  
wrote:

RMC was previously configured to work only with the systemd-boot EFI
bootloader. With this commit we can specify alternative bootloaders by
setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is
not set systemd-boot will be used by default.

Signed-off-by: Todor Minchev 
---
Remove references to grub-efi and gummiboot from V1.

classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} |  5 +++--
conf/machine/include/meta-intel.inc|  2 +-
documentation/rmc/README   | 16 +---
3 files changed, 17 insertions(+), 6 deletions(-)
rename classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} (73%)

diff --git a/classes/rmc-systemd-boot.bbclass b/classes/rmc-boot.bbclass
similarity index 73%
rename from classes/rmc-systemd-boot.bbclass
rename to classes/rmc-boot.bbclass
index ad2cf10..a1f2093 100644
--- a/classes/rmc-systemd-boot.bbclass
+++ b/classes/rmc-boot.bbclass
@@ -1,9 +1,10 @@
-# rmc-systemd-boot bbclass
+# rmc-boot bbclass
# Deploy central RMC database file to ESP

IMAGE_INSTALL_append = " rmc"
+RMC_BOOTLOADER ?= "systemd-boot”

Maybe this is what we could have now without bothering OE. It is better than 
the corrent code at the cost of another variable to user. I hope in the future 
we could get rid of  the dependency to EFI_PROVIDER (e.g. bz10084).

Also refer to my comment for the document change at the below.

-inherit systemd-boot
+inherit ${RMC_BOOTLOADER}

do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"

diff --git a/conf/machine/include/meta-intel.inc 
b/conf/machine/include/meta-intel.inc
index c7555ce..fd0a792 100644
--- a/conf/machine/include/meta-intel.inc
+++ b/conf/machine/include/meta-intel.inc
@@ -32,7 +32,7 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = 
"${@bb.utils.contains('MACHINE_FEATURE
# merge the microcode data in the final initrd image.
INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', 
'${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"

-EFI_PROVIDER ?= "rmc-systemd-boot"
+EFI_PROVIDER ?= "rmc-boot"

# Add general MACHINEOVERRIDE for meta-intel
MACHINEOVERRIDES =. "intel-x86-common:"
diff --git a/documentation/rmc/README b/documentation/rmc/README
index 2427ffd..dbee6b6 100644
--- a/documentation/rmc/README
+++ b/documentation/rmc/README
@@ -165,14 +165,24 @@ steps still can override results from this hook for boot 
entries and KBOOTPARAM.

Enable RMC Feature

-To Enable RMC feature in build, add the below lines in a conf file:
+To enable the RMC feature please add the following variables to your 
local.conf.
+
DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"
+
+The default EFI bootloader used with RMC is systemd-boot. To change the default
+bootloader please overwrite the RMC_BOOTLOADER variable in your local.conf

Note:
Image could be still bootable if you only have either of two lines, but RMC
feature won't be fully functional.

+To install only the RMC client with the systemd-boot bootloader without
+including a default RMC database file, add the following lines to your
+local.conf:
+
+EFI_PROVIDER = "systemd-boot"
+IMAGE_INSTALL_append = " rmc”

I think this use case could confuse for user without much benefit. And actually 
they still can set EFI_PROVIDER to any available efi bootloaders to get this 
effect as long as it is not “rmc-boot”, right?
Maybe we should just say “you won’t get rmc database deployed if you set 
EFI_PROVIDER to any values not rmc-boot."

Yes, this can be another way to phrase this.


Examples
@@ -190,7 +200,7 @@ EXAMPLE 1: Support a new board type:
(1) enable the feature and do a build to get a live-boot image by adding these
 lines in conf/local.conf:
 DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"

(2) flash the image to a USB stick and boot it on your board

--
2.11.0





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

Re: [meta-intel] [PATCH] galileodisk-sd.wks: Add rootwait

[Cal Sullivan]

Works for me.

On 11/22/2016 01:58 PM, Saul Wold wrote:

Adding rootwait to the kernel params in order to handle the fact that
4.8 boots faster and older SD cards are not ready in time for the kernel
to correctly mount.

[YOCTO #10709]

Signed-off-by: Saul Wold 

Tested-by: California Sullivan 

---
  scripts/lib/wic/canned-wks/galileodisk-sd.wks | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/canned-wks/galileodisk-sd.wks 
b/scripts/lib/wic/canned-wks/galileodisk-sd.wks
index 6d96af4..de8807d 100644
--- a/scripts/lib/wic/canned-wks/galileodisk-sd.wks
+++ b/scripts/lib/wic/canned-wks/galileodisk-sd.wks
@@ -6,4 +6,4 @@ part /boot --source bootimg-efi 
--sourceparams="loader=systemd-boot" --ondisk mm
  
  part / --source rootfs --ondisk mmcblk0 --fstype=ext3 --label platform --align 1024 --use-uuid
  
-bootloader  --timeout=0  --append="console=ttyS1,115200n8 earlycon=uart8250,mmio32,0x9000b000,115200n8 reboot=efi,warm apic=debug rw LABEL=boot debugshell=5"

+bootloader  --timeout=0  --append="rootwait console=ttyS1,115200n8 
earlycon=uart8250,mmio32,0x9000b000,115200n8 reboot=efi,warm apic=debug rw LABEL=boot 
debugshell=5"


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

Re: [meta-intel] [PATCH] meta-intel: Enable RMC by default

[Cal Sullivan]

On 10/17/2016 03:02 PM, Saul Wold wrote:

This enables the Runtime Machine Configuration feature, which
allows use to support multiple machines that have different
kernel commandline option as well as different startup requirements
to work from the base MACHINE configuration.

Signed-off-by: Saul Wold 
---
  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 94dab6e..0d6e119 100644
--- a/conf/machine/include/meta-intel.inc
+++ b/conf/machine/include/meta-intel.inc
@@ -31,3 +31,8 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = 
"${@bb.utils.contains('MACHINE_FEATURE
  # for the early boot time kernel microcode loading support,
  # merge the microcode data in the final initrd image.
  INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', 
'${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"
+
+# Enable Runtime Machine Config by default
+DISTRO_FEATURES_append = " rmc"
+EFI_PROVIDER ?= "rmc-systemd-boot"
+


Probably don't need this extra whitespace at the end of the file.

---
Cal

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

Re: [meta-intel] standard/intel/base revisions

[Cal Sullivan]

+ Bruce again. I somehow dropped him a few emails back. Pretty important 
information about the old and new standard/intel/base branches diverging.


---
Cal

On 10/03/2016 02:20 PM, Cal Sullivan wrote:



On 10/03/2016 02:10 PM, Patrick Ohly wrote:

On Mon, 2016-10-03 at 12:59 -0700, Cal Sullivan wrote:
My local linux-yocto-4.4 branch was at that commit ID, and after 
doing a

git fetch and git status I see the following:

[clsulliv@clsulliv linux-yocto-4.4]$ git st
On branch standard/intel/base
Your branch and 'origin/standard/intel/base' have diverged,
and have 1327 and 325 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)

So something definitely seems wrong.

Now, to add some confusion to the problem, when I build using upstream
meta-intel, it has no issue building with those commit IDs. Even wiping
out my build directory (and thus getting rid of tmp, sstate, and
downloads) it still fetches and builds successfully.

Are you 100% sure it fetches the kernel source anew and doesn't reuse
some locally cached or mirrored repo? linux-yocto's log.do_fetch might
show that.


You're right, it looks likeits actually pulling from a mirror:
DEBUG: For url 
git://git.yoctoproject.org/linux-yocto-4.4.git;name=machine;branch=standard/intel/base; 
returning 
http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-4.4.git.tar.gz


It looks like it was last updated September 13th, explaining why it 
has the correct commit IDs.


---
Cal



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

Re: [meta-intel] standard/intel/base revisions

[Cal Sullivan]

On 10/03/2016 02:10 PM, Patrick Ohly wrote:

On Mon, 2016-10-03 at 12:59 -0700, Cal Sullivan wrote:

My local linux-yocto-4.4 branch was at that commit ID, and after doing a
git fetch and git status I see the following:

[clsulliv@clsulliv linux-yocto-4.4]$ git st
On branch standard/intel/base
Your branch and 'origin/standard/intel/base' have diverged,
and have 1327 and 325 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)

So something definitely seems wrong.

Now, to add some confusion to the problem, when I build using upstream
meta-intel, it has no issue building with those commit IDs. Even wiping
out my build directory (and thus getting rid of tmp, sstate, and
downloads) it still fetches and builds successfully.

Are you 100% sure it fetches the kernel source anew and doesn't reuse
some locally cached or mirrored repo? linux-yocto's log.do_fetch might
show that.


You're right, it looks likeits actually pulling from a mirror:
DEBUG: For url 
git://git.yoctoproject.org/linux-yocto-4.4.git;name=machine;branch=standard/intel/base; 
returning 
http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-4.4.git.tar.gz


It looks like it was last updated September 13th, explaining why it has 
the correct commit IDs.


---
Cal

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

Re: [meta-intel] standard/intel/base revisions

[Cal Sullivan]

My local linux-yocto-4.4 branch was at that commit ID, and after doing a 
git fetch and git status I see the following:


[clsulliv@clsulliv linux-yocto-4.4]$ git st
On branch standard/intel/base
Your branch and 'origin/standard/intel/base' have diverged,
and have 1327 and 325 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

So something definitely seems wrong.

Now, to add some confusion to the problem, when I build using upstream 
meta-intel, it has no issue building with those commit IDs. Even wiping 
out my build directory (and thus getting rid of tmp, sstate, and 
downloads) it still fetches and builds successfully.


---
Cal

On 10/03/2016 12:38 PM, Patrick Ohly wrote:

On Mon, 2016-10-03 at 12:30 -0700, Saul Wold wrote:

On Mon, 2016-10-03 at 14:42 -0400, Bruce Ashfield wrote:


On Mon, Oct 3, 2016 at 1:07 PM, Cal Sullivan  wrote:

+ Bruce

I also can't find that revision on the remote branch...

There were some fixups lately, but yah, I don't see that revision
either. One of the
rebase branches was force updated for those cleanups, but not
standard/intel/base.

So it's not certain yet how this happened? I think it would be
worthwhile to investigate, to ensure that similar mistakes won't happen
again.


Either way, I sent a pull request late last night that has the
revisions I've been testing
so they should work.

Does that bring back 94e5bb30ea onto the standard/intel/base branch?


The problem is that the current and existing Ostro Project is using the
hash in question and so missing it from the existing 4.4 will cause
issues for them.

Not just Ostro - unless I miss something, anyone using the current
meta-intel will be unable to build the 4.4 kernel from upstream sources.


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

Re: [meta-intel] standard/intel/base revisions

[Cal Sullivan]

+ Bruce

I also can't find that revision on the remote branch...

---
Cal

On 10/02/2016 08:24 AM, Patrick Ohly wrote:

On Sat, 2016-10-01 at 13:49 +0200, Patrick Ohly wrote:

Hello!

I'm getting the following error when trying to build for
intel-corei7-64:

ERROR: linux-yocto-4.4.20+gitAUTOINC+59290c5f61_94e5bb30ea-r0 do_fetch:
Fetcher failure: Unable to find revision
94e5bb30eaf8a880a6c82b64a497d8b4a855d138 in branch standard/intel/base
even from upstream

That's for SRCREV_MACHINE_INTEL_COMMON =
"94e5bb30eaf8a880a6c82b64a497d8b4a855d138" in current
meta-intel/common/recipes-kernel/linux/linux-yocto_4.4.bbappend. And
indeed, that revision no longer seems to be on the standard/intel/base
branch (or any branch at all, if I understand "git branch --contains"
correctly):

$ cd linux-yocto-4.4/
$ git fetch origin
$ git branch --contains 94e5bb30eaf8a880a6c82b64a497d8b4a855d138 | wc -l
0
$ git log --oneline origin/standard/intel/base | grep 94e5bb | wc -l
0

Has someone accidentally force-pushed a new standard/intel/base branch?

https://download.ostroproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-4.4.git.tar.gz
 has a copy of the repo where 94e5bb is on the standard/intel/base branch.



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

Re: [meta-intel] [PATCH 1/2] linux-yocto/4.4: Bump SRCREVs from v4.4.18 to v4.4.20

[Cal Sullivan]

Yep, sorry about that. I had a patch in my queue to fix this, but hadn't 
gotten around to it yet. Sent it off just now.


Thanks,
Cal

On 09/22/2016 11:31 AM, Trevor Woerner wrote:

On Mon 2016-09-12 @ 02:38:04 PM, California Sullivan wrote:

 From linux-yocto-4.4:

---
  common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend   | 4 ++--
  common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 4 ++--
  common/recipes-kernel/linux/linux-yocto_4.4.bbappend  | 4 ++--
  3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend 
b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
index f0dd1e0..b228941 100644
--- a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
@@ -1,8 +1,8 @@
  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
  
  LINUX_VERSION_INTEL_COMMON = "4.4.18"

The above, and subsequent, need to be:
LINUX_VERSION_INTEL_COMMON = "4.4.20"

otherwise:

ERROR: linux-yocto-rt-4.4.18+gitAUTOINC+59290c5f61_b5e21aa988-r0 
do_kernel_version_sanity_check: Package Version 
(4.4.18+gitAUTOINC+59290c5f61_b5e21aa988) does not match of kernel being built 
(4.4.20). Please update the PV variable to match the kernel source.
ERROR: linux-yocto-rt-4.4.18+gitAUTOINC+59290c5f61_b5e21aa988-r0 
do_kernel_version_sanity_check: Function failed: do_kernel_version_sanity_check 
(log file is located at 
/z/layerindex-master/minnowmax/tmp/work/corei7-64-intel-common-fortress-linux/linux-yocto-rt/4.4.18+gitAUTOINC+59290c5f61_b5e21aa988-r0/temp/log.do_kernel_version_sanity_check.20430)
ERROR: Logfile of failure stored in: 
/z/layerindex-master/minnowmax/tmp/work/corei7-64-intel-common-fortress-linux/linux-yocto-rt/4.4.18+gitAUTOINC+59290c5f61_b5e21aa988-r0/temp/log.do_kernel_version_sanity_check.20430
ERROR: Task 
(/z/layerindex-master/layers/openembedded-core/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb:do_kernel_version_sanity_check)
 failed with exit code '1'


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

Re: [meta-intel] [PATCH 1/1] linux-yocto: Add linux-yocto_4.8.bbappend

[Cal Sullivan]

Please disregard this. I have a better patch set coming.

Thanks,
Cal

On 09/06/2016 04:30 PM, California Sullivan wrote:

Preliminary testing on the 4.8 kernel has gone well with no major
defects found on Intel hardware.

Tiny is not yet in a working condition and the preempt-rt patches are
not yet available for the -rt kernel, so only add the base linux-yocto
recipe for now.

Signed-off-by: California Sullivan 
---
  .../recipes-kernel/linux/linux-yocto_4.8.bbappend  | 41 ++
  1 file changed, 41 insertions(+)
  create mode 100644 common/recipes-kernel/linux/linux-yocto_4.8.bbappend

diff --git a/common/recipes-kernel/linux/linux-yocto_4.8.bbappend 
b/common/recipes-kernel/linux/linux-yocto_4.8.bbappend
new file mode 100644
index 000..412accf
--- /dev/null
+++ b/common/recipes-kernel/linux/linux-yocto_4.8.bbappend
@@ -0,0 +1,41 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+LINUX_VERSION_INTEL_COMMON = "4.8.0-rc4"
+SRCREV_META_INTEL_COMMON = "8cb7317502c2577f8c83eaf1c061603023824313"
+SRCREV_MACHINE_INTEL_COMMON = "a7d71794e4e38d2f861c1b1dbff761ae0b0836b3"
+
+KBRANCH_INTEL_COMMON = "standard/base"
+
+LINUX_VERSION_core2-32-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
+COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
+KMACHINE_core2-32-intel-common = "intel-core2-32"
+KBRANCH_core2-32-intel-common = "${KBRANCH_INTEL_COMMON}"
+SRCREV_meta_core2-32-intel-common ?= "${SRCREV_META_INTEL_COMMON}"
+SRCREV_machine_core2-32-intel-common ?= "${SRCREV_MACHINE_INTEL_COMMON}"
+KERNEL_FEATURES_append_core2-32-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON}"
+
+LINUX_VERSION_corei7-64-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
+COMPATIBLE_MACHINE_corei7-64-intel-common = "${MACHINE}"
+KMACHINE_corei7-64-intel-common = "intel-corei7-64"
+KBRANCH_corei7-64-intel-common = "${KBRANCH_INTEL_COMMON}"
+SRCREV_meta_corei7-64-intel-common ?= "${SRCREV_META_INTEL_COMMON}"
+SRCREV_machine_corei7-64-intel-common ?= "${SRCREV_MACHINE_INTEL_COMMON}"
+KERNEL_FEATURES_append_corei7-64-intel-common = 
"${KERNEL_FEATURES_INTEL_COMMON}"
+
+# Quark / X1000 BSP Info
+LINUX_VERSION_i586-nlp-32-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
+COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
+KMACHINE_i586-nlp-32-intel-common = "intel-quark"
+KBRANCH_i586-nlp-32-intel-common = "${KBRANCH_INTEL_COMMON}"
+SRCREV_meta_i586-nlp-32-intel-common ?= "${SRCREV_META_INTEL_COMMON}"
+SRCREV_machine_i586-nlp-32-intel-common ?= "${SRCREV_MACHINE_INTEL_COMMON}"
+KERNEL_FEATURES_append_i586-nlp-32-intel-common = ""
+
+
+# For Crystalforest and Romley
+KERNEL_MODULE_AUTOLOAD_append_core2-32-intel-common = " uio"
+KERNEL_MODULE_AUTOLOAD_append_corei7-64-intel-common = " uio"
+
+# For FRI2, NUC
+KERNEL_MODULE_AUTOLOAD_append_core2-32-intel-common = " iwlwifi"
+KERNEL_MODULE_AUTOLOAD_append_corei7-64-intel-common = " iwlwifi"


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

Re: [meta-intel] [PATCH 1/2] intel-corei7-64: add machine configurations specific to leafhill bsp

[Cal Sullivan]

On 09/06/2016 10:43 AM, Saul Wold wrote:

On Mon, 2016-09-05 at 14:18 +0800, Rebecca Chang Swee Fun wrote:

We would like to enable new BSP for Intel Atom E3900 SoC based
platforms.
This will help us to consolidate BSP into intel-common and we can use
KERNEL_FEATURES to select target BSP to compile.

Leaf Hill uses different serial console port setup. Hence this
mechanism are in place to enable new bsp with existing machine
configurations file.

Leaf Hill BSP also required additional kernel stack protector
settings to compile kernel with security defense enabled.


Is this for Jethro, Kroghoth, master?

more comments below


Signed-off-by: Rebecca Chang Swee Fun

---
  conf/machine/intel-corei7-64.conf | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/conf/machine/intel-corei7-64.conf b/conf/machine/intel-
corei7-64.conf
index cc16d62..7a5b400 100644
--- a/conf/machine/intel-corei7-64.conf
+++ b/conf/machine/intel-corei7-64.conf
@@ -29,6 +29,9 @@ XSERVER ?= "${XSERVER_X86_BASE} \
  ${XSERVER_X86_VESA} \
 "
  
-SYSLINUX_OPTS = "serial 0 115200"

-SERIAL_CONSOLE = "115200 ttyS0"
-APPEND += "console=ttyS0,115200 console=tty0"
+SYSLINUX_OPTS = "serial ${@bb.utils.contains('KERNEL_FEATURES',
'leafhill', '2', '0', d)} 115200"
+SERIAL_CONSOLE = "115200 ${@bb.utils.contains('KERNEL_FEATURES',
'leafhill', 'ttyS2', 'ttyS0', d)}"

Can we not use the SERIAL_CONSOLES = "115200,ttyS2 115200,ttyS0"
variable here instead?


I think doing a switch based on KERNEL_FEATURES doesn't scale well and 
makes things a lot less readable.


We can also do this:

SERIAL_CONSOLES = "115200,ttyS2 115200,ttyS0"
SERIAL_CONSOLES_CHECK = "ttyS2 ttyS0"

This should stop getty from trying to enable non-existent serial consoles, stopping the 
annoying "trying to respawn" warning we would get every five minutes otherwise.





+APPEND += "${@bb.utils.contains('KERNEL_FEATURES', 'leafhill',
'console=ttyS2,115200n8', 'console=ttyS0,115200', d)} console=tty0"
+APPEND += "${@bb.utils.contains('KERNEL_FEATURES', 'leafhill',
'reboot=efi kmemleak=off i915.enable_ipc=1', '', d)}"

So the console settings I understand, but I think we can set multiple
consoles on the command line.

Yep, multiple consoles in APPEND is fine. We do it in core2 already.


Moving forward for 2.2 and beyond, you should start learning about the
"Runtime Machine Config" RMC that was recently introduced into meta-
intel for 2.2


+
+KERNEL_EXTRA_ARGS = "${@bb.utils.contains('KERNEL_FEATURES',
'leafhill', 'EXTRA_CFLAGS="-D_FORTIFY_SOURCE=2 -Wformat -O2 -Wformat-
security"', '', d)}"

Do we really need to change the CFLAGS here?  Would the be appropriate
for all kernels moving forward?  These seem more like product quality
or maybe distro related CFLAGS than BSP generic flags.

We want to keep the difference between a non-intel-core* bsp and the
intel-core* bsps to a minimum, this will always guarantee they are
different

Agree here.

---
Cal

Sau!



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

Re: [meta-intel] [PATCH 0/2] linux-yocto SRCREV update 9/1

[Cal Sullivan]

+ Tom.

Sorry, accidentally did @yoctoproject.org instead of @intel.com!

On 09/01/2016 04:46 PM, California Sullivan wrote:

Hi Tom,

This week's update fixes the architecture mismatch for quark MACHINEs
for 4.4, the architecture mismatch for quark and core2 for 4.1, the
configuration warnings with the new kernel tools for core2 and corei7,
and updates the 4.1 kernel to v4.1.30.

No new errors or warning were revealed in my normal smoke testing, and
as usual the patches are also available at my branch here:

git://git.yoctoproject.org/meta-intel-contrib -b clsulliv/master-test

Thanks,
Cal Sullivan

California Sullivan (2):
   linux-yocto/4.4: Update SRCREVs for intel-quark fix
   linux-yocto/4.1: Update SRCREVs for v4.1.30 and fix config for new
 tools

  common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend   | 6 +++---
  common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend   | 4 ++--
  common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 6 +++---
  common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 4 ++--
  common/recipes-kernel/linux/linux-yocto_4.1.bbappend  | 6 +++---
  common/recipes-kernel/linux/linux-yocto_4.4.bbappend  | 4 ++--
  6 files changed, 15 insertions(+), 15 deletions(-)



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