Re: [meta-intel] [PATCH] uefi-comboapp.bbclass: install files under pseudo

[Wold, Saul]

On Wed, 2017-11-15 at 19:13 +0100, Patrick Ohly wrote:
> On Wed, 2017-11-15 at 17:35 +0000, Wold, Saul wrote:
> > Thanks, does this require a backport to Rocko/8.0.0 also?
> 
> It's also broken there and it would be useful to backport it.
> 
Pushed to master and rocko!

Thanks
   Sau!

> -- 
> Best Regards, Patrick Ohly
> 
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
> 
> 
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] uefi-comboapp.bbclass: install files under pseudo

[Wold, Saul]

On Wed, 2017-11-15 at 10:36 +0100, Patrick Ohly wrote:
> do_uefiapp_deploy copies files into the /boot directory of the rootfs
> and thus, like do_rootfs, should run under pseudo so that the files
> end up being owned by root.
> 
> This did not trigger the uid leak check, perhaps because the task
> runs
> later.
> 
> For some (still unknown reason), sometimes the installed files did
> end
> up being owned by root, which tripped up a swupd test because the
> system update randomly included unexpected changes to bootx64.efi or
> rmc.db. With this change, they are owned by root consistently.
> 
Patrick, 

Thanks, does this require a backport to Rocko/8.0.0 also?

Sau!

> Signed-off-by: Patrick Ohly 
> ---
>  classes/uefi-comboapp.bbclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/classes/uefi-comboapp.bbclass b/classes/uefi-
> comboapp.bbclass
> index 5c3ca8c..4ecc553 100644
> --- a/classes/uefi-comboapp.bbclass
> +++ b/classes/uefi-comboapp.bbclass
> @@ -101,14 +101,14 @@ uefiapp_deploy_at() {
>  done
>  }
>  
> -do_uefiapp_deploy() {
> +fakeroot do_uefiapp_deploy() {
>  rm -rf ${IMAGE_ROOTFS}/boot/*
>  dest=${IMAGE_ROOTFS}/boot/EFI/BOOT
>  mkdir -p $dest
>  uefiapp_deploy_at $dest
>  }
>  
> -do_uefiapp_deploy[depends] += "${PN}:do_uefiapp"
> +do_uefiapp_deploy[depends] += "${PN}:do_uefiapp virtual/fakeroot-
> native:do_populate_sysroot"
>  
>  
>  # This decides when/how we add our tasks to the image
> 
> base-commit: 863590f9bc7104fef698ce6b89ec24dfce542df1
> -- 
> git-series 0.9.1
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [meta-intel-qat][PATCH] qat: upgrade to version 17_1.0.3-42

[Wold, Saul]

On Fri, 2017-10-20 at 23:39 +0800, Tan, Raymond wrote:
> > -Original Message-
> > From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel-
> > boun...@yoctoproject.org] On Behalf Of Wold, Saul
> > Sent: Tuesday, October 10, 2017 10:09 PM
> > To: meta-intel@yoctoproject.org; Syed Mohamad Fauzi, Syed Johan
> > Arif
> > <syed.johan.arif.syed.mohamad.fa...@intel.com>
> > Subject: Re: [meta-intel] [meta-intel-qat][PATCH] qat: upgrade to
> > version
> > 17_1.0.3-42
> > 
> > On Tue, 2017-10-10 at 09:11 +, Syed Mohamad Fauzi, Syed Johan
> > Arif
> > wrote:
> > > Please ignore this, I wasn't supposed to remove qat16
> > > 
> > 
> > Why not?
> > 
> > We normally do not include multiple version of the same upstream in
> > order
> > to avoid confusion, is there a specific reason we need to maintain
> > the qat16
> > version?
> 
> Hi Saul,
> 
> qat16  is still in place to give support of older QAT 1.6 HW version
> (older platforms released in 2015/16).
> 
My specific concern is around the fact it provides an older version of
openssl that might contain CVEs.

Sau!

> > 
> > Sau!
> > 
> > > -Original Message-
> > > From: Syed Mohamad Fauzi, Syed Johan Arif
> > > Sent: Tuesday, October 10, 2017 4:20 PM
> > > To: meta-intel@yoctoproject.org
> > > Cc: Syed Mohamad Fauzi, Syed Johan Arif
> > >  > > .fa...@intel.com>; Tan, Raymond <raymond@intel.com>
> > > Subject: [meta-intel-qat][PATCH] qat: upgrade to version
> > > 17_1.0.3-42
> > > 
> > > Dear maintainer,
> > > 
> > > This patch upgrades qat to version 17_1.0.3-42
> > > 
> > > Syed Mohamad Fauzi, Syed Johan Arif (1):
> > >   qat: upgrade to version 17_1.0.3-42
> > > 
> > >  recipes-extended/qat/qat16.inc | 123 ---
> > >  ...salServices-Only-use-bits-time-with-GLIBC.patch |  27
> > > --  ...t16_2.3.0-34-make-sure-CFLAGS-are-correct.patch |  30
> > > --  0-34-qat-fix-for-cross-compilation-issue.patch |  40 -
> > > --  0-34-qat-remove-local-path-from-makefile.patch |  31
> > > --  ...qat16_2.5.0-80-qat-Added-include-dir-path.patch |  30
> > > --  0-80-qat-add-install-target-to-makefiles.patch | 387 
> > > 
> > > -  ...nge-in-return-type-of-func-in-kernel-v4.4.patch
> > > >  40 ---  0-65-qat-add-install-target-to-makefiles.patch |
> > > > 353
> > > 
> > > ---  ...rride-CC-LD-AR-only-when-it-is-not-
> > > define.patch |  35 --
> > >  recipes-extended/qat/qat16/use-CC-for-LD.patch |  17 -
> > >  recipes-extended/qat/qat16_2.5.0-80.bb |  12 -
> > >  recipes-extended/qat/qat16_2.6.0-65.bb |  16 -
> > >  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 ++
> > >  20 files changed, 360 insertions(+), 1141 deletions(-)  delete
> > > mode
> > > 100644 recipes-extended/qat/qat16.inc  delete mode 100644
> > > recipes-
> > > extended/qat/qat16/0001-OsalServices-Only-use-bits-time-with-
> > > GLIBC.patch
> > >  delete mode 100644 recipes-extended/qat/qat16/qat16_2.3.0-34-
> > > make-
> > > sure-CFLAGS-are-correct.patch
> > >  delete mode 100644 recipes-extended/qat/qat16/qat16_2.3.0-34-
> > > qat-
> > > fix-for-cross-compilation-issue.patch
> > >  delete mode 100644 recipes-extended/qat/qat16/qat16_2.3.0-34-
> > > qat-
> > > remove-local-path-from-makefile.patch
> > >  delete mode 100644 recipes-extended/qat/qat16/qat16_2.5.0-80-
> > > qat-
> > > Added-include-dir-path.patch
> > >  delete mode 100644 recipes-extended/qat/qat16/qat16_2.5.0-80-
> > > qat-
> > > add-install-target-to-makefiles.patch
> > >  delete mode 100644 recipes-extended/qat/qat16/qat16_2.5.0-80-
> > > qat-
> > > change-in-return-type-of-func-in-kernel-v4.4.patch
> > >  delete mode 100644 recipes-extended/qat/qat16/qat16_2.6.0-65-
> > > qat-
> > > add-install-target-

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

[Wold, Saul]

On Thu, 2017-10-12 at 09:52 +, Syed Mohamad Fauzi, Syed Johan Arif
wrote:
> I'm not sure why the upstream isn't updated with the new/different
> firmware.
>  The firmware is coming from
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
> firmware.git/
Yes, there is qat*.bin files in linux-firmware, is the firmware in the
upstream QAT source, different than the firmware in linux-firmware
repo?

If not, let's just RDEPEND on linux-firmware, I am going to break the
qat blobs out into a linux-firmware-qat package, unless it should be
finer grained down to the 3 different variations (qat_89*, qat_c6* and
qat_c3xxx*.bin), let me know what you think.

If we need to setup a quick meeting, ping me on Skype, I gather your in
Penang, I will be available later today.

> Regarding openssl-qat updates I'd need to ask Raymond about that, can
> I get back to you on that later?

Thanks.

Sau!

> Hope this helps.
> 

> Kind regards
> Johan
> 
> -----Original Message-
> From: Wold, Saul
> Sent: Tuesday, October 10, 2017 10:38 PM
> To: meta-intel@yoctoproject.org; Syed Mohamad Fauzi, Syed Johan Arif
> <syed.johan.arif.syed.mohamad.fa...@intel.com>
> Cc: syed.johan.arif.syed.mohamad.fa...@gmail.com
> Subject: Re: [meta-intel] [PATCH] linux-firmware: remove qat from
> linux-firmware
> 
> 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
> > <syed.johan.arif.syed.mohamad.fa...@intel.com>
> > ---
> >  .../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
> > 
-- 
___
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

[Wold, Saul]

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
> 
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [meta-intel-qat][PATCH] qat: upgrade to version 17_1.0.3-42

[Wold, Saul]

On Tue, 2017-10-10 at 09:11 +, Syed Mohamad Fauzi, Syed Johan Arif
wrote:
> Please ignore this, I wasn't supposed to remove qat16
> 
Why not?

We normally do not include multiple version of the same upstream in
order to avoid confusion, is there a specific reason we need to
maintain the qat16 version?

Sau!

> -Original Message-
> From: Syed Mohamad Fauzi, Syed Johan Arif 
> Sent: Tuesday, October 10, 2017 4:20 PM
> To: meta-intel@yoctoproject.org
> Cc: Syed Mohamad Fauzi, Syed Johan Arif  .fa...@intel.com>; Tan, Raymond 
> Subject: [meta-intel-qat][PATCH] qat: upgrade to version 17_1.0.3-42
> 
> Dear maintainer, 
> 
> This patch upgrades qat to version 17_1.0.3-42
> 
> Syed Mohamad Fauzi, Syed Johan Arif (1):
>   qat: upgrade to version 17_1.0.3-42
> 
>  recipes-extended/qat/qat16.inc | 123 ---
>  ...salServices-Only-use-bits-time-with-GLIBC.patch |  27
> --  ...t16_2.3.0-34-make-sure-CFLAGS-are-correct.patch |  30
> --  0-34-qat-fix-for-cross-compilation-issue.patch |  40 -
> --  0-34-qat-remove-local-path-from-makefile.patch |  31
> --  ...qat16_2.5.0-80-qat-Added-include-dir-path.patch |  30
> --  0-80-qat-add-install-target-to-makefiles.patch | 387 
> -  ...nge-in-return-type-of-func-in-kernel-v4.4.patch
> |  40 ---  0-65-qat-add-install-target-to-makefiles.patch | 353
> ---  ...rride-CC-LD-AR-only-when-it-is-not-
> define.patch |  35 --
>  recipes-extended/qat/qat16/use-CC-for-LD.patch |  17 -
>  recipes-extended/qat/qat16_2.5.0-80.bb |  12 -
>  recipes-extended/qat/qat16_2.6.0-65.bb |  16 -
>  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 ++
>  20 files changed, 360 insertions(+), 1141 deletions(-)  delete mode
> 100644 recipes-extended/qat/qat16.inc  delete mode 100644 recipes-
> extended/qat/qat16/0001-OsalServices-Only-use-bits-time-with-
> GLIBC.patch
>  delete mode 100644 recipes-extended/qat/qat16/qat16_2.3.0-34-make-
> sure-CFLAGS-are-correct.patch
>  delete mode 100644 recipes-extended/qat/qat16/qat16_2.3.0-34-qat-
> fix-for-cross-compilation-issue.patch
>  delete mode 100644 recipes-extended/qat/qat16/qat16_2.3.0-34-qat-
> remove-local-path-from-makefile.patch
>  delete mode 100644 recipes-extended/qat/qat16/qat16_2.5.0-80-qat-
> Added-include-dir-path.patch
>  delete mode 100644 recipes-extended/qat/qat16/qat16_2.5.0-80-qat-
> add-install-target-to-makefiles.patch
>  delete mode 100644 recipes-extended/qat/qat16/qat16_2.5.0-80-qat-
> change-in-return-type-of-func-in-kernel-v4.4.patch
>  delete mode 100644 recipes-extended/qat/qat16/qat16_2.6.0-65-qat-
> add-install-target-to-makefiles.patch
>  delete mode 100644 recipes-extended/qat/qat16/qat16_2.6.0-65-qat-
> override-CC-LD-AR-only-when-it-is-not-define.patch
>  delete mode 100644 recipes-extended/qat/qat16/use-CC-for-LD.patch
>  delete mode 100644 recipes-extended/qat/qat16_2.5.0-80.bb
>  delete mode 100644 recipes-extended/qat/qat16_2.6.0-65.bb
>  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
> 
> --
> 1.9.1
> 
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] Issue with ovmf license under Pyro

[Wold, Saul]

On Wed, 2017-10-04 at 09:00 +0200, Dominig ar Foll (Intel Open Source)
wrote:
> Hello,
> 
> I can confirm that the error is a bit random but fairly systematic on
> my system.
> I build on master from AGL. My source statement come from http://docs
> .automotivelinux.org/docs/getting_started/en/dev/reference/machines/i
> ntel.html
> 
>   source meta-agl/scripts/aglsetup.sh \
>   -m intel-corei7-64 \
>   -b build \
>   agl-devel agl-demo agl-appfw-smack agl-netboot
> 
> Mikko finding seems to be pointing to a similar issue.
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12070
> 
I need must be doing something wrong, I don't get a build with that, it
just setups up the config and spits out a list of images that can be
built.

Sau!

> Regards
> 
> Dominig
> 
> 
> Le 04/10/2017 à 07:17, Mikko Ylinen a écrit :
> > Hi, 
> > 
> > A bugzilla search for 'do_image_complete' gave me https://bugzilla.
> > yoctoproject.org/show_bug.cgi?id=12070 
> > 
> > -- Mikko 
> > 
> > 
> > On 03/10/17 21:59, Paul Eggleton wrote: 
> > > I've heard occasional reports of this issue as well and I believe
> > > it has to do 
> > > with the exact sequence of actions up to receiving the error -
> > > just setting 
> > > the configuration to be the same won't trigger it. Perhaps you
> > > need to add 
> > > something to the image and then remove it, perhaps removing the
> > > recipe 
> > > altogether? Not sure. 
> > > 
> > > Cheers, 
> > > Paul 
> > > 
> > > On Wednesday, 4 October 2017 4:38:27 AM NZDT Wold, Saul wrote: 
> > > > On Mon, 2017-10-02 at 19:41 +0200, Dominig Ar Foll wrote: 
> > > > > Hello, 
> > > > > 
> > > > > I am seeing an issue with the ovmf license in AGL,  since
> > > > > yocto has 
> > > > > moved to Pyro. 
> > > > > I can fix by deactivating it, but I do not understand why I
> > > > > see the 
> > > > > error. 
> > > > > 
> > > >  Hi Dominig, 
> > > > 
> > > > I tried to build the AGL code based on the website, I did not
> > > > see this, 
> > > > so clearly your using different branches or code. 
> > > > 
> > > > Could you point me at what your actually using please, I want
> > > > to 
> > > > confirm is this is an AGL issue or an OE-Core/meta-intel
> > > > issue. 
> > > > 
> > > > I tried with AGL master and moved meta-intel to master (from
> > > > pyro), but 
> > > > could not reproduce this issue. 
> > > > 
> > > > 
> > > > > So it will come back each time that I sync on meta-intel
> > > > > agin. 
> > > > > 
> > > > > Any help would be welcome. 
> > > > > Log and corrective patches are bellow. 
> > > > > 
> > > >  That's not really an acceptable patch for this situation. 
> > > > 
> > > > Sau! 
> > > > 
> > > > > Any help would be welcome. 
> > > > > 
> > >  
> >  
>  
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] Issue with ovmf license under Pyro

[Wold, Saul]

On Mon, 2017-10-02 at 19:41 +0200, Dominig Ar Foll wrote:
> Hello,
> 
> I am seeing an issue with the ovmf license in AGL,  since yocto has
> moved to Pyro.
> I can fix by deactivating it, but I do not understand why I see the
> error.
> 
Hi Dominig, 

I tried to build the AGL code based on the website, I did not see this,
so clearly your using different branches or code.

Could you point me at what your actually using please, I want to
confirm is this is an AGL issue or an OE-Core/meta-intel issue.

I tried with AGL master and moved meta-intel to master (from pyro), but
could not reproduce this issue.


> So it will come back each time that I sync on meta-intel agin.
> 
> Any help would be welcome.
> Log and corrective patches are bellow.
> 
That's not really an acceptable patch for this situation.

Sau!

> Any help would be welcome.
> 
> -- 
> Dominig ar Foll
> Senior Software Architect
> Intel Open Source Technology Centre
> 
> 
> ---log -
> ERROR: initramfs-netboot-image-1.0-r0 do_image_complete: Error
> executing a python function in exec_python_func() autogenerated:
> 
> The stack trace of python calls that resulted in this
> exception/failure was:
> File: 'exec_python_func() autogenerated', lineno: 2, function:
> 
>  0001:
>  *** 0002:write_deploy_manifest(d)
>  0003:
> File: '/home/dominig/AGL/poky/meta/classes/license.bbclass', lineno:
> 33, function: write_deploy_manifest
>  0029:'w+').write(output)
>  0030:}
>  0031:
>  0032:python write_deploy_manifest() {
>  *** 0033:license_deployed_manifest(d)
>  0034:}
>  0035:
>  0036:python license_create_manifest() {
>  0037:import oe.packagedata
> File: '/home/dominig/AGL/poky/meta/classes/license.bbclass', lineno:
> 192, function: license_deployed_manifest
>  0188:man_dic[dep]["IMAGE_MANIFEST"] = True
>  0189:man_dic[dep]["PN"] = dep
>  0190:man_dic[dep]["FILES"] = \
>  0191:" ".join(get_deployed_files(dep_dic[dep]))
>  *** 0192:with open(os.path.join(lic_dir, dep, "recipeinfo"),
> "r") as f:
>  0193:for line in f.readlines():
>  0194:key,val = line.split(": ", 1)
>  0195:man_dic[dep][key] = val[:-1]
>  0196:
> Exception: FileNotFoundError: [Errno 2] No such file or directory:
> '/home/dominig/AGL/build/tmp/deploy/licenses/ovmf/recipeinfo'
> 
> ERROR: initramfs-netboot-image-1.0-r0 do_image_complete: Function
> failed: write_deploy_manifest
> ERROR: Logfile of failure stored in:
> /home/dominig/AGL/build/tmp/work/intel_corei7_64-agl-linux/initramfs-
> netboot-image/1.0-r0/temp/log.do_image_complete.19739
> ERROR: Task (/home/dominig/AGL/meta-agl/meta-netboot/recipes-
> core/images/initramfs-netboot-image.bb:do_image_complete)
> failed with exit code '1'
> -- Patch ---
> diff --git a/conf/machine/include/qemu-intel.inc
> b/conf/machine/include/qemu-intel.inc
> index 8151040..f167f4c 100644
> --- a/conf/machine/include/qemu-intel.inc
> +++ b/conf/machine/include/qemu-intel.inc
> @@ -5,7 +5,8 @@
>  EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
> 
>  # Build ovmf firmware for uefi support in qemu.
> -EXTRA_IMAGEDEPENDS += "ovmf"
> +# Deactivated as crashes under Yocto 2.3 (Pyro)
> +#EXTRA_IMAGEDEPENDS += "ovmf"
> 
>  # runqemu uses virtio, so we have to enable the corresponding
>  # kernel drivers.
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] meta-intel.inc: Avoid installing thermald on poky-tiny

[Wold, Saul]

On Tue, 2017-09-26 at 09:11 +0300, Jussi Laako wrote:
> On 25.09.2017 10:00, Mikko Ylinen wrote:
> > On 23/09/17 01:03, Alejandro Hernandez wrote:
> > > When using DISTRO=poky-tiny we dont need to have thermald
> > > and also it brings about ~4MB of dependencies.
> > 
> > It's conceptually not right to have a distro dependency in the
> > BSP settings, IMO.
> > 
> > If your distro/image does not need something the BSP thinks is
> > necessary, the distro/image itself should deal with that.
> 
> This is problem to a bigger extent too. Many BSPs try to pull in all 
> kinds of extra things, such as gstreamer plugins, even if the image 
> being built doesn't need such things.
> 
And Distro's don't know what a BSP might pull in, so they can't
directly _remove or exclude them somehow.

> I think it is overall a bad idea to force BSP to pull in lot of high 
> level user space components by default that are not essential for
> the 
> basic functionality (boot-to-init), be it thermald or gstreamer. 

Generally agreed, I am not sure I would call thermald high-level, it is
targeted for Intel hardware, just as we pull in the microcode to ensure
that is updated for the hardware.

Maybe we should move thermald to RRECOMMENDS in the case of meta-intel
instead of RDEPENDS

> This 
> doesn't apply only to poky-tiny, but to many other distros too. I
> would 
> rather like to see those as optional extra that can be enabled
> through a 
> variable.
> 
Would RRECOMMENDS be sufficient?  What kind of variable something that
says the BSP can add stuff or not?

Sau!

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

Re: [meta-intel] DPDK -- move to a separate sublayer

[Wold, Saul]

On Mon, 2017-09-25 at 12:54 +, Tan, Raymond wrote:
> Hi Mark,
> 
> 
> > -Original Message-
> > From: Mark Hatle [mailto:mark.ha...@windriver.com]
> > Sent: Wednesday, September 20, 2017 11:30 PM
> > To: meta-intel@yoctoproject.org
> > Cc: Tan, Raymond <raymond@intel.com>; Wold, Saul
> > <saul.w...@intel.com>
> > Subject: DPDK -- move to a separate sublayer
> > 
> > I am looking at using the meta-intel version of DPDK for our
> > customers, but
> > including all of meta-intel is problematic for me.  (We currently
> > have our own
> > dpdk layer and recipes -- which I'd like to get rid of.)
> > 
> > The issue is that DPDK is not Intel specific.  Other architectures,
> > vendors can
> > and do use DPDK for their components.
> 
> Agree on this, in fact for DPDK alone, there were a request came in
> for Mellanox card months ago,
> thus the dpdk-libibverbs recipe.
> 
> > 
> > Right now to use DPDK, I'm having to use BBMASK to disable pretty
> > much
> > everything else in meta-intel for the systems I am trying to
> > support.
> > 
> > What I would like to propose is moving dpdk into a sublayer of
> > meta-intel (or
> > an external layer.)
> 
> I'm not sure about the sublayer design, perhaps Saul would have
> better input on this? 

I would suggest an external layer

> I think this boils down to what is the role of meta-intel, is it a
> common layer for IA-based platforms?

meta-intel is meant to be a BSP layer, so more focused in IA-based
platforms.
>  
> Or it's a layer to host software/firmware from Intel? 
>  
As a BSP layer it should be more focused on platforms and not software
from Intel. There are a number of other layers for Intel software.
 
> > I spoke to Saul about this briefly to see if it sounded like a
> > reasonable idea,
> > and at least on the surface it seems reasonable.
> > 
> > Is this something you would be interested in doing?  If so, I can
> > prepare
> > patches to construct the new sublayer and move the associate
> > package(s)
> > into that layer.
> 
> Would this be in time for the Rocko release / meta-intel 8.0 ? 
> 
It could work for meta-intel 8.0 since we are independent of the Rocko
release itself.  If Mark can pull together the patches to create a
separate layers for both DPDK and I guess QAT, that would be great.

Sau!

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

Re: [meta-intel] meta-mono build boot kernel panic

[Wold, Saul]

On Sat, 2017-09-23 at 16:07 +0800, Lai Eddy wrote:
> I have build and boot successfully the core-image-minial with
> MACHINE = "intel-corei7-64"
> 
> but after I add according to http://git.yoctoproject.org/cgit/cgit.cg
> i/meta-mono/about/?h=daisy
> IMAGE_INSTALL += " mono mono-helloworld"
> (also with bblayers.conf changed correctly)
> 
> build core-image-mono and then boot failed with panic:
>  switch_root: can't execute '/sbin/init': No such file or directory
>  Kernel panic - not syncing: Attempted to kill init!
> 
> could this be a mono configuration problem or a processor related
> problem ?
> 
Based on your config below, you are adding more than mono, I would ask
the question of did it work before adding mono and some of the
additional layers?  Some layer is modifying /sbin/init, so I don't
think it's a processor related problem.

Sau!

> Build Configuration:
> BB_VERSION= "1.34.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "universal"
> TARGET_SYS= "x86_64-poky-linux"
> MACHINE   = "intel-corei7-64"
> DISTRO= "poky"
> DISTRO_VERSION= "2.3.1"
> TUNE_FEATURES = "m64 corei7"
> TARGET_FPU= ""
> meta  
> meta-poky 
> meta-yocto-bsp= "pyro:4a39979c8d1e560fa54240e99734a651dfbaa63a"
> meta-cloud-services 
> meta-openstack= "master:19f0c979abbc72a300c0b1cb92f9328f96728f5a"
> meta-intel= "pyro:16aea09d224f3ed2021623d17c3e807f4b8ff18d"
> meta-oe   
> meta-python   
> meta-networking   = "master:4a45235796df0ca1b3bca5407b9615281cf8889d"
> meta-mono = "master:a6d24311ccdc1dd6fd205489cde4590d1b327990"
> 
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH v2] linux-firware_%.bbappend: multiple fixes

[Wold, Saul]

On Mon, 2017-09-11 at 14:26 -0700, California Sullivan wrote:
> Fix yocto project compatibility issue: was using raw _appends,
> without a
> machineoverride.
> 
> Fix not pinning to a specific commit ID. The firmware could be
> updated,
> which would change the hash and break the build temporarily.
> 
> Fix naming. There are several similarly named firmware blobs (e.g.,
> iwlwifi-8265-31) so not using the real name of the blob was
> confusing.
> 
> Signed-off-by: California Sullivan 
> ---
> v2: Fix do_install:
> pinning to a specific commit caused wget to save the ?id=commitish as
> part of the file name. Not sure why this didn't occur with my initial
> testing.
> 
>  .../recipes-kernel/linux-firmware/linux-firmware_%.bbappend  | 12
> +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/common/recipes-kernel/linux-firmware/linux-
> firmware_%.bbappend b/common/recipes-kernel/linux-firmware/linux-
> firmware_%.bbappend
> index 50836ee..f6968af 100644
> --- a/common/recipes-kernel/linux-firmware/linux-firmware_%.bbappend
> +++ b/common/recipes-kernel/linux-firmware/linux-firmware_%.bbappend
> @@ -10,12 +10,14 @@
>  # Note: keep these in sync when updating the iwlwifi_git.bb
> LinuxCore
>  # versions.
>  
> -SRC_URI_append = " https://git.kernel.org/pub/scm/linux/kernel/git/i
> wlwifi/linux-firmware.git/plain/iwlwifi-8000C-31.ucode;name=iwlwifi-
> 8260-31"
> +SRC_URI_append_intel-x86-common = " https://git.kernel.org/pub/scm/l
> inux/kernel/git/iwlwifi/linux-firmware.git/plain/iwlwifi-8000C-
> 31.ucode?id=${IWLWIFI_SRCREV};name=iwlwifi-8000C-31"
>  
> -SRC_URI[iwlwifi-8260-31.md5sum] = "428a84a780bbe864a7af6a6734c4b529"
> -SRC_URI[iwlwifi-8260-31.sha256sum] =
> "5a337c52f9d7a7cb5cb0a13c93232f4de742ed0debef757d68231bdb55455406"
> +IWLWIFI_SRCREV = "942f14f65363f33c3fd8a06db58c8ccca0559335"
>  
> -do_install_append() {
> +SRC_URI[iwlwifi-8000C-31.md5sum] =
> "428a84a780bbe864a7af6a6734c4b529"
> +SRC_URI[iwlwifi-8000C-31.sha256sum] =
> "5a337c52f9d7a7cb5cb0a13c93232f4de742ed0debef757d68231bdb55455406"
> +
I think these need _intel-x86-common overrides to prevent signature
checks changing.

Sau!

> +do_install_append_intel-x86-common() {
>  # Copy the iwlwifi/LinuxCore required ucode for Intel Wireless
> 8260
> -cp ${WORKDIR}/iwlwifi-8000C-31.ucode
> ${D}/${nonarch_base_libdir}/firmware/
> +cp ${WORKDIR}/iwlwifi-8000C-31.ucode\?id\=${IWLWIFI_SRCREV}
> ${D}/${nonarch_base_libdir}/firmware/iwlwifi-8000C-31.ucode
>  }
> -- 
> 2.9.5
> 
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] Xeon D1500 GPIO userspace access write error: No such device or address

[Wold, Saul]

On Fri, 2017-09-01 at 09:12 +0800, Lai Eddy wrote:
> I have just build and run Yocto(Pyro 2.3.1) Linux on my Xeon D1500
> board, 
> I want to use the SOC's GPIO pins for a push button, so I use
> "bitbake linux-yocto -c menuconfig" to enable the 
> "Device Drivers"-->"GPIO Support"-->"sysfs interface", and also
> enable the "Intel ICH GPIO"
> after the kernel boot on the board, there's a gpiochip available:
> # cd /sys/class/gpio/
> # ls
> exportgpiochip436  unexport
> # more gpiochip436/ngpio 
> 76
> but I got an error when I issue the command to export GPIO#1 
> # echo 436 > export
> -sh: echo: write error: No such device or address
> # echo 437 > export
> -sh: echo: write error: No such device or address
> 
> is there kernel miss configured or something wrong on the operation?
> 
Can you also verify with the output of dmesg that the gpio device is
initialized?

Sau!

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

Re: [meta-intel] [PATCH V3 2/3] linux-yocto: remove ixgbe and ixgbevf

[Wold, Saul]

On Wed, 2017-08-23 at 17:12 +0800, Syed Mohamad Fauzi, Syed Johan Arif
wrote:
> removing in-tree ixgbe and ixgbevf kernel module to enable out-of-
> tree ixgbe and ixgbevf module from linux-yocto 4.4
> 
> Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif  yed.mohamad.fa...@intel.com>
> ---
>  common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
> b/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
> index c20f748..92233b0 100644
> --- a/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
> +++ b/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
> @@ -33,7 +33,6 @@ 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"
> @@ -41,3 +40,9 @@ 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"
> +
> +do_compile_kernelmodules_append() {
> + rm -rf ${B}/drivers/net/ethernet/intel/ixgbe
> + rm -rf ${B}/drivers/net/ethernet/intel/ixgbevf
> + rm -rf ${B}/net/ethernet
> +}

Drop this patch as I will not merge it for linux-yocto, only linux-
intel.

Sau!


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

Re: [meta-intel] [PATCH V2 2/3] linux-intel: remove ixgbe and ixgbevf

[Wold, Saul]

On Tue, 2017-08-22 at 15:39 +0300, Mikko Ylinen wrote:
> Hi,
> 
> 
> On 21/08/17 09:26, Syed Mohamad Fauzi, Syed Johan Arif wrote:
> > 
> > removing in-tree ixgbe and ixgbevf kernel modules to enable out-of-
> > tree ixgbe and ixgbevf modules from linux-intel
> > 
> > Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif  > .syed.mohamad.fa...@intel.com>
> > ---
> >   common/recipes-kernel/linux/linux-intel.inc | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/common/recipes-kernel/linux/linux-intel.inc
> > b/common/recipes-kernel/linux/linux-intel.inc
> > index 20f01f0..3b0c576 100644
> > --- a/common/recipes-kernel/linux/linux-intel.inc
> > +++ b/common/recipes-kernel/linux/linux-intel.inc
> > @@ -38,6 +38,8 @@ do_compile_kernelmodules_append() {
> >     rm -rf ${B}/drivers/net/wireless/intel/iwlwifi
> >     rm -rf ${B}/net/mac80211
> >     rm -rf ${B}/net/wireless
> > +   rm -rf ${B}/drivers/net/ethernet/intel/ixgbe
> > +   rm -rf ${B}/drivers/net/ethernet/intel/ixgbevf
> >   }
> >   
> >   RDEPENDS_kernel-modules += "iwlwifi"
> 
> This does not look right (the same for iwlwifi).  Why not to disable
> the config fragments if the modules are not wanted?
> 
Mikko,

Since we are using the same base yocto-kernel-cache data for both the
linux-intel and linux-yocto kernel, the value add by the linux-intel
kernel is that it uses the out of tree modules (newer, shiner, better),
while the linux-yocto kernel still needs to have the iwlwifi and ixgbe
drivers there, since it does not DEPEND on the iwlwifi OOT modules.

So removal is easiest.

Sau!


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

Re: [meta-intel] BSP QA Test Report for Meta-Intel Release 2.4 M2 rc2

[Wold, Saul]

Thanks for this report, as stated below, we had one issue related to
the new iwlwifi and another parselog (bane of my existence at this
point).

The iwlwifi has been address and merged, so that bug can be closed, I
will not do an RC3.

I know the parselog issues are accumlating, some should get whitelisted
while other investigated further, I think the older one dealing with
blk_update_request has to do with hddimg and loopback mount, so we
should white list this one until we move completely to WIC and
installed images.

Sau!


On Wed, 2017-08-16 at 05:10 +, Cruz, Libertad wrote:
>  
> Hello,
>  
> QA test cycle is complete full report:
>  
> https://wiki.yoctoproject.org/wiki/WW33_-_2017-08-15-_Full_Test_Cycle
> _-_2.4_M2_rc2_-_meta-intel
>  
>  Summary 
>  
> The QA cycle for release 2.4 M2 rc2 Meta-Intel is complete, there are
> two new bugs 11935 which has been given a medium + priority and has a
> working patch that was not integrated into the build. Bug 11937 not
> yet been evaluated.
>  
>  Details 
> Bugs
>  
> * New
> · 11935 Connman fails to scan wifi ap on automatic refresh
> due to firmware loading errors
> · 11937 [Testcase 1059] Parselogs is failing corei7-64-lsb on
> Cherry Hill giving error: *ERROR* timed out waiting for Punit DDR
> DVFS request
>  
> * Not New
> · 10455 [morty][Test Case 1059] Parselogs is failing on
> genericx86 (32 and 64 bits) giving error: blk_update_request: I/O
> error, dev loop0
>  
>     
>  Links =
>  
> 1 – https://bugzilla.yoctoproject.org/show_bug.cgi?id=11935
> 2 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=11937
> 3 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=10455
>  
> ==
>  
>  
> Regards,
> Libertad G.
>  
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] libyami: Fix build with musl/clang

[Wold, Saul]

On Mon, 2017-08-14 at 09:23 -0700, Khem Raj wrote:
> On Mon, Aug 14, 2017 at 7:21 AM, Wold, Saul <saul.w...@intel.com>
> wrote:
> > 
> > On Fri, 2017-08-11 at 21:17 -0700, Khem Raj wrote:
> > > 
> > > These patches are interesting from upstreaming point of view as
> > > well
> > > 
> > Khem,
> > 
> > If they are good for Upstream, are you submitting them upstream,
> > can
> > you add Upstream-Status: ... to these patches please so we can
> > track
> > them
> > 
> 
> Sure I could. Will send a v2.
> 
Could you do that for the whole series you sent this weekend also,
please.

Thanks!

Sau!

> > 
> > Sau!
> > 
> > 
> > > 
> > > Signed-off-by: Khem Raj <raj.k...@gmail.com>
> > > ---
> > >  ...01-bitWriter.cpp-Delete-unused-CACHEBYTES.patch |  25 
> > >  .../0002-typecast-index-from-size_t-to-int.patch   |  40 +++
> > >  ...-invalid-offsetof-to-compiler-commandline.patch |  27 +
> > >  .../0004-Typecast-POWER32SUB2-to-uint8_t.patch |  31 +
> > >  ...-move-c-definitions-out-of-extern-C-block.patch | 128
> > > +
> > >  ...pace-conflicts-by-adding-explicit-using-n.patch |  39 +++
> > >  .../libyami/0007-Delete-unused-variables.patch |  34 ++
> > >  ...alUnit-is-declared-in-different-namespace.patch |  29 +
> > >  .../libyami/libyami/0009-Fix-clang-warnings.patch  |  35 ++
> > >  common/recipes-multimedia/libyami/libyami_1.2.0.bb |  12 +-
> > >  10 files changed, 399 insertions(+), 1 deletion(-)
> > >  create mode 100644 common/recipes-
> > > multimedia/libyami/libyami/0001-
> > > bitWriter.cpp-Delete-unused-CACHEBYTES.patch
> > >  create mode 100644 common/recipes-
> > > multimedia/libyami/libyami/0002-
> > > typecast-index-from-size_t-to-int.patch
> > >  create mode 100644 common/recipes-
> > > multimedia/libyami/libyami/0003-
> > > Add-Wno-invalid-offsetof-to-compiler-commandline.patch
> > >  create mode 100644 common/recipes-
> > > multimedia/libyami/libyami/0004-
> > > Typecast-POWER32SUB2-to-uint8_t.patch
> > >  create mode 100644 common/recipes-
> > > multimedia/libyami/libyami/0005-
> > > move-c-definitions-out-of-extern-C-block.patch
> > >  create mode 100644 common/recipes-
> > > multimedia/libyami/libyami/0006-
> > > Avoid-namespace-conflicts-by-adding-explicit-using-n.patch
> > >  create mode 100644 common/recipes-
> > > multimedia/libyami/libyami/0007-
> > > Delete-unused-variables.patch
> > >  create mode 100644 common/recipes-
> > > multimedia/libyami/libyami/0008-
> > > NalUnit-is-declared-in-different-namespace.patch
> > >  create mode 100644 common/recipes-
> > > multimedia/libyami/libyami/0009-
> > > Fix-clang-warnings.patch
> > > 
> > > diff --git a/common/recipes-multimedia/libyami/libyami/0001-
> > > bitWriter.cpp-Delete-unused-CACHEBYTES.patch b/common/recipes-
> > > multimedia/libyami/libyami/0001-bitWriter.cpp-Delete-unused-
> > > CACHEBYTES.patch
> > > new file mode 100644
> > > index 000..5109166
> > > --- /dev/null
> > > +++ b/common/recipes-multimedia/libyami/libyami/0001-
> > > bitWriter.cpp-
> > > Delete-unused-CACHEBYTES.patch
> > > @@ -0,0 +1,25 @@
> > > +From 294874b610a5b8af9b736b3afc938010af58785e Mon Sep 17
> > > 00:00:00
> > > 2001
> > > +From: Khem Raj <raj.k...@gmail.com>
> > > +Date: Fri, 11 Aug 2017 17:15:45 -0700
> > > +Subject: [PATCH 1/9] bitWriter.cpp: Delete unused CACHEBYTES
> > > +
> > > +Signed-off-by: Khem Raj <raj.k...@gmail.com>
> > > +---
> > > + codecparsers/bitWriter.cpp | 1 -
> > > + 1 file changed, 1 deletion(-)
> > > +
> > > +diff --git a/codecparsers/bitWriter.cpp
> > > b/codecparsers/bitWriter.cpp
> > > +index 9bcb14d..08469bf 100644
> > > +--- a/codecparsers/bitWriter.cpp
> > >  b/codecparsers/bitWriter.cpp
> > > +@@ -24,7 +24,6 @@
> > > +
> > > + namespace YamiParser {
> > > +
> > > +-const uint32_t CACHEBYTES = sizeof(unsigned long int);
> > > + const uint32_t CACHEBITS = sizeof(unsigned long int) * 8;
> > > +
> > > + // clip to keep lowest n bits
> > > +--
> > > +2.14.1
> > > +
> > > diff --git a/common/recipes-multimedia/libyami/libyami/0002-
> > > typecast-
> > > index-from-s

Re: [meta-intel] [PATCH 3/3] linux-intel: remove ixgbe and ixgbevf

[Wold, Saul]

On Thu, 2017-08-10 at 13:21 +0800, Syed Mohamad Fauzi, Syed Johan Arif
wrote:
> removing in-tree ixgbe and ixgbevf kernel modules to enable out-of-
> tree ixgbe and ixgbevf modules from linux-intel
> 
> Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif  yed.mohamad.fa...@intel.com>
> ---
>  common/recipes-kernel/linux/linux-intel.inc | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/common/recipes-kernel/linux/linux-intel.inc
> b/common/recipes-kernel/linux/linux-intel.inc
> index 20f01f0..d23751c 100644
> --- a/common/recipes-kernel/linux/linux-intel.inc
> +++ b/common/recipes-kernel/linux/linux-intel.inc
> @@ -38,6 +38,9 @@ do_compile_kernelmodules_append() {
>   rm -rf ${B}/drivers/net/wireless/intel/iwlwifi
>   rm -rf ${B}/net/mac80211
>   rm -rf ${B}/net/wireless
> + rm -rf ${B}/drivers/net/ethernet/intel/ixgbe
> + rm -rf ${B}/drivers/net/ethernet/intel/ixgbevf
> + rm -rf ${B}/net/ethernet
Why remove the net/ethernet directory here?  Are there files installed
in this location by either of the ixgbe* driver?

Sau!
>  }
>  
>  RDEPENDS_kernel-modules += "iwlwifi"
> -- 
> 1.9.1
> 
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 1/3] intel-ethernet: IXGBE upgrade to version 5.1.3

[Wold, Saul]

On Thu, 2017-08-10 at 13:21 +0800, Syed Mohamad Fauzi, Syed Johan Arif
wrote:
> From: Syed Johan Arif Bin Syed Mohamad Fauzi  hamad.fa...@intel.com>
> 
Almost there!  There are a few more tweaks needed.

> Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif
> 
> ---
>  .../recipes-kernel/intel-ethernet/ixgbe_5.1.3.bb   | 40
> +
>  .../ixgbevf/0002-ixgbevf_common.patch  | 23 
>  .../recipes-kernel/intel-ethernet/ixgbevf_4.1.2.bb | 41
> ++
>  3 files changed, 104 insertions(+)
>  create mode 100644 common/recipes-kernel/intel-
> ethernet/ixgbe_5.1.3.bb
>  create mode 100644 common/recipes-kernel/intel-
> ethernet/ixgbevf/0002-ixgbevf_common.patch
>  create mode 100644 common/recipes-kernel/intel-
> ethernet/ixgbevf_4.1.2.bb
> 
> diff --git a/common/recipes-kernel/intel-ethernet/ixgbe_5.1.3.bb
> b/common/recipes-kernel/intel-ethernet/ixgbe_5.1.3.bb
> new file mode 100644
> index 000..bc1feef
> --- /dev/null
> +++ b/common/recipes-kernel/intel-ethernet/ixgbe_5.1.3.bb
> @@ -0,0 +1,40 @@
> +SUMMARY="ixgbe kernel driver for Intel Magnolia Park 10GbE"
> +DESCRIPTION="Intel 10-Gbps Ethernet driver for Magnolia Park"
> +AUTHOR = "Ong Boon Leong"
> +HOMEPAGE = "http://www.intel.com/network/connectivity/products/serve
> r_adapters.htm"
> +SECTION = "kernel/network"
> +LICENSE = "GPLv2"
> +LIC_FILES_CHKSUM = "file://${WORKDIR}/${PN}-
> ${PV}/COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> +
> +SRC_URI  = "https://sourceforge.net/projects/e1000/files/ixgbe%20sta
> ble/${PV}/${PN}-${PV}.tar.gz"
> +
> +SRC_URI[md5sum] = "ae35ed547aa6a5087672c3f70ce1e676"
> +SRC_URI[sha256sum] =
> "9f537d79bddf0a087a17af632d57812d26d26bcfebbd4bdcf10df656ff055bb4"
> +
> +S = "${WORKDIR}/${PN}-${PV}/src"
> +SCRIPT_DIR = "${WORKDIR}/${PN}-${PV}/scripts"
> +
> +EXTRA_OEMAKE='KSRC="${STAGING_KERNEL_BUILDDIR}"
> KVER="${KERNEL_VERSION}" \
> +  BUILD_ARCH="${TARGET_ARCH}" PREFIX="${D}" \
> +  SYSTEM_MAP_FILE="${STAGING_KERNEL_BUILDDIR}/System.map
> -${KERNEL_VERSION}" INSTALL_MOD_PATH="${D}"'
> +
> +KERNEL_MODULE_AUTOLOAD_append_intel-core2-32 = " ixgbe"
> +KERNEL_MODULE_AUTOLOAD_append_intel-corei7-64 = " ixgbe"
> +
> +inherit module
> +
> +MODULES_INSTALL_TARGET = "install"
> +
> +do_install_append () {
> + # Remove man and additional module info
> + rm -rf ${D}${prefix}/man
> + rm -rf
> ${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/modules.*
> +
> +# Install scripts/set_irq_affinity
> +install -d  ${D}/etc/network
> +install -m 0755
> ${SCRIPT_DIR}/set_irq_affinity  ${D}/etc/network
> +}
> +
> +PACKAGES += "${PN}-script"
> +
> +FILES_${PN}-script += "/etc/network/set_irq_affinity"

The "/etc" references should really be ${sysconfdir} here and above


> diff --git a/common/recipes-kernel/intel-ethernet/ixgbevf/0002-
> ixgbevf_common.patch b/common/recipes-kernel/intel-
> ethernet/ixgbevf/0002-ixgbevf_common.patch
> new file mode 100644
> index 000..d442e24
> --- /dev/null
> +++ b/common/recipes-kernel/intel-ethernet/ixgbevf/0002-
> ixgbevf_common.patch
> @@ -0,0 +1,23 @@
> +From f74fbcd821a394dec58263fd2c2ea62eae298b2f Mon Sep 17 00:00:00
> 2001
> +From: "Goh, Wen Sen" 
> +Date: Sun, 26 Jun 2016 12:01:36 +0800
> +Subject: [PATCH] ixgbevf patch
> +
Please add a Signed-off-by and Upstream-Status to the 0002-
ixbgevf_common.patch file.


> +---
> + common.mk | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/common.mk b/common.mk
> +index b9b01c7..228a926 100644
> +--- a/common.mk
>  b/common.mk
> +@@ -289,6 +289,7 @@ export INSTALL_MOD_DIR ?=
> updates/drivers/net/ethernet/intel/${DRIVER}
> + kernelbuild = ${MAKE} $(if ${GCC_I_SYS},CC="${GCC_I_SYS}") \
> +   ${CCFLAGS_VAR}="${EXTRA_CFLAGS}" \
> +   -C "${KSRC}" \
> ++  CONFIG_IXGBE=m \
> +   CONFIG_${DRIVER_UPPERCASE}=m \
> +   M="${CURDIR}" \
> +   ${2} ${1};
> +--
> +2.8.3
> diff --git a/common/recipes-kernel/intel-ethernet/ixgbevf_4.1.2.bb
> b/common/recipes-kernel/intel-ethernet/ixgbevf_4.1.2.bb
> new file mode 100644
> index 000..1a92677
> --- /dev/null
> +++ b/common/recipes-kernel/intel-ethernet/ixgbevf_4.1.2.bb
> @@ -0,0 +1,41 @@
> +SUMMARY="ixgbevf kernel driver for Intel Magnolia Park 10GbE"
> +DESCRIPTION="Intel 10-Gbps Ethernet driver for Magnolia Park"
> +AUTHOR = "Ong Boon Leong"
> +HOMEPAGE = "http://www.intel.com/network/connectivity/products/serve
> r_adapters.htm"
> +SECTION = "kernel/network"
> +LICENSE = "GPLv2"
> +LIC_FILES_CHKSUM = "file://${WORKDIR}/${PN}-
> ${PV}/COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> +
> +SRC_URI  = "https://sourceforge.net/projects/e1000/files/ixgbevf%20s
> table/${PV}/${PN}-${PV}.tar.gz"
> +SRC_URI += "file://0002-ixgbevf_common.patch"
> +
> +SRC_URI[md5sum] = "f02ec46369d1ca949a1e9d2e0eb74d5f"
> 

Re: [meta-intel] [PATCH] dpdk: DPDK upgrade to version 17.05

[Wold, Saul]

On Thu, 2017-07-27 at 08:54 +, Syed Mohamad Fauzi, Syed Johan Arif
wrote:
> The patch can't apply because of a difference between the master
> branch and pyro.
> I noticed that the master branch has a dpdk related commit that is
> not incorporated in the pyro branch.
> I'm referring to commit d90da5961da727d28a963f814cd164c0abf24bbf,
> dpdk: Disable build for MUSL.
> Will this commit be incorporated in the pyro branch?
> 
This patch must be applied to master.  Also, we don't typically
backport package upgrades to older releases, unless there is a clear
security issue, normally we would back port patches to fix CVE issues.

Sau!


> Kind regards
> Johan
> 
> -----Original Message-
> From: Wold, Saul
> Sent: Thursday, July 27, 2017 12:31 AM
> To: meta-intel@yoctoproject.org; Syed Mohamad Fauzi, Syed Johan Arif
> <syed.johan.arif.syed.mohamad.fa...@intel.com>
> Subject: Re: [meta-intel] [PATCH] dpdk: DPDK upgrade to version 17.05
> 
> 
> 
> This patch does not apply to the master branch of meta-intel, you
> need to ensure this is against master please.
> 
> Thanks
>    Sau!
> 
> 
> On Wed, 2017-07-26 at 16:23 +0800, Syed Mohamad Fauzi, Syed Johan
> Arif
> wrote:
> > 
> > Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif
> >  > yed.mohamad.fa...@intel.com>
> > ---
> >  common/recipes-extended/dpdk/dpdk.inc  |  6 +--
> >  ...onfig-variable-to-enable-disable-dpdk_qat.patch | 31 --
> > --
> > 
> >  ...4-point-to-the-right-include-and-lib-path.patch | 43 --
> > --
> > --
> >  ...dk-16.07-dpdk-fix-for-parellel-make-issue.patch |  6 +--
> >  common/recipes-extended/dpdk/dpdk_17.02.bb | 19 --
> >  common/recipes-extended/dpdk/dpdk_17.05.bb | 18 +
> >  6 files changed, 24 insertions(+), 99 deletions(-)  delete mode
> > 100644 common/recipes-extended/dpdk/dpdk/dpdk-16.04-add-
> > config-variable-to-enable-disable-dpdk_qat.patch
> >  delete mode 100644 common/recipes-extended/dpdk/dpdk/dpdk-16.04-
> > point-to-the-right-include-and-lib-path.patch
> >  delete mode 100644 common/recipes-extended/dpdk/dpdk_17.02.bb
> >  create mode 100644 common/recipes-extended/dpdk/dpdk_17.05.bb
> > 
> > diff --git a/common/recipes-extended/dpdk/dpdk.inc
> > b/common/recipes-
> > extended/dpdk/dpdk.inc index 77bd4a8..b8bd2ad 100644
> > --- a/common/recipes-extended/dpdk/dpdk.inc
> > +++ b/common/recipes-extended/dpdk/dpdk.inc
> > @@ -6,14 +6,13 @@ LIC_FILES_CHKSUM = "file://LICENSE.GPL;md5=751419
> > 26
> > 0aa954499f7abaabaa882bbe"
> >  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-point-to-the-right-include-and-lib-
> > path.patch \
> > file://dpdk-16.04-Fix-for-misleading-indentation-
> > error.patch \
> > file://dpdk-16.04-dpdk-fix-compilation-with-dynamic-
> > libs.patch \
> > file://dpdk-16.07-dpdk-fix-for-parellel-make-issue.patch
> > \
> > file://dpdk-17.02-dpdk-fix-installation-warning-and-
> > issue.patch \
> >    "
> > 
> > -COMPATIBLE_MACHINE = "intel-corei7-64"
> > +COMPATIBLE_MACHINE = "crystalforest|intel-corei7-64|intel-core2-
> > 32"
> > 
> >  # dpdk example apps dpdk_qat and vhost have dependancy on fuse and
> > qat.
> >  # fuse is in meta-filesystems and qat is not yet upstreamed.
> > @@ -59,7 +58,8 @@ def get_dpdk_target_mach(bb, d):
> >  "mohonpeak64":"atm",
> >  "mohonpeak32":"atm",
> >  "crystalforest":  "ivb",
> > -"intel_corei7_64": "hsw",
> > +"intel_corei7_64": "atm",
> > +"intel_core2_32": "atm",
> >  }
> > 
> >  if target_arch in multiarch_options :
> > diff --git a/common/recipes-extended/dpdk/dpdk/dpdk-16.04-add-
> > config-
> > variable-to-enable-disable-dpdk_qat.patch b/common/recipes-
> > extended/dpdk/dpdk/dpdk-16.04-add-config-variable-to-enable-
> > disable-
> > dpdk_qat.patch
> > deleted file mode 100644
> > index cd51705..000
> > --- a/common/recipes-extended/dpdk/dpdk/dpdk-16.04-add-config-
> > variable-to-enable-disable-dpdk_qat.patch
> > +++ /dev/null
> > @@ -1,31 +0,0 @@
> > -From a424a79b1422f1877de3ee7aee6f781aeacc3630 Mon Sep 17

Re: [meta-intel] [PATCH] dpdk: DPDK upgrade to version 17.05

[Wold, Saul]

This patch does not apply to the master branch of meta-intel, you need
to ensure this is against master please.

Thanks
   Sau!


On Wed, 2017-07-26 at 16:23 +0800, Syed Mohamad Fauzi, Syed Johan Arif
wrote:
> Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif  yed.mohamad.fa...@intel.com>
> ---
>  common/recipes-extended/dpdk/dpdk.inc  |  6 +--
>  ...onfig-variable-to-enable-disable-dpdk_qat.patch | 31 
> 
>  ...4-point-to-the-right-include-and-lib-path.patch | 43 
> --
>  ...dk-16.07-dpdk-fix-for-parellel-make-issue.patch |  6 +--
>  common/recipes-extended/dpdk/dpdk_17.02.bb | 19 --
>  common/recipes-extended/dpdk/dpdk_17.05.bb | 18 +
>  6 files changed, 24 insertions(+), 99 deletions(-)
>  delete mode 100644 common/recipes-extended/dpdk/dpdk/dpdk-16.04-add-
> config-variable-to-enable-disable-dpdk_qat.patch
>  delete mode 100644 common/recipes-extended/dpdk/dpdk/dpdk-16.04-
> point-to-the-right-include-and-lib-path.patch
>  delete mode 100644 common/recipes-extended/dpdk/dpdk_17.02.bb
>  create mode 100644 common/recipes-extended/dpdk/dpdk_17.05.bb
> 
> diff --git a/common/recipes-extended/dpdk/dpdk.inc b/common/recipes-
> extended/dpdk/dpdk.inc
> index 77bd4a8..b8bd2ad 100644
> --- a/common/recipes-extended/dpdk/dpdk.inc
> +++ b/common/recipes-extended/dpdk/dpdk.inc
> @@ -6,14 +6,13 @@ LIC_FILES_CHKSUM = "file://LICENSE.GPL;md5=75141926
> 0aa954499f7abaabaa882bbe"
>  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-point-to-the-right-include-and-lib-
> path.patch \
>      file://dpdk-16.04-Fix-for-misleading-indentation-
> error.patch \
>      file://dpdk-16.04-dpdk-fix-compilation-with-dynamic-
> libs.patch \
>      file://dpdk-16.07-dpdk-fix-for-parellel-make-issue.patch
> \
>      file://dpdk-17.02-dpdk-fix-installation-warning-and-
> issue.patch \
>     "
>  
> -COMPATIBLE_MACHINE = "intel-corei7-64"
> +COMPATIBLE_MACHINE = "crystalforest|intel-corei7-64|intel-core2-32"
>  
>  # dpdk example apps dpdk_qat and vhost have dependancy on fuse and
> qat.
>  # fuse is in meta-filesystems and qat is not yet upstreamed.
> @@ -59,7 +58,8 @@ def get_dpdk_target_mach(bb, d):
>  "mohonpeak64":"atm",
>  "mohonpeak32":"atm",
>  "crystalforest":  "ivb",
> -"intel_corei7_64": "hsw",
> +"intel_corei7_64": "atm",
> + "intel_core2_32": "atm",
>  }
>  
>  if target_arch in multiarch_options :
> diff --git a/common/recipes-extended/dpdk/dpdk/dpdk-16.04-add-config-
> variable-to-enable-disable-dpdk_qat.patch b/common/recipes-
> extended/dpdk/dpdk/dpdk-16.04-add-config-variable-to-enable-disable-
> dpdk_qat.patch
> deleted file mode 100644
> index cd51705..000
> --- a/common/recipes-extended/dpdk/dpdk/dpdk-16.04-add-config-
> variable-to-enable-disable-dpdk_qat.patch
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -From a424a79b1422f1877de3ee7aee6f781aeacc3630 Mon Sep 17 00:00:00
> 2001
> -From: Anuj Mittal 
> -Date: Tue, 18 Aug 2015 12:36:02 +0800
> -Subject: [PATCH] examples: add config variable to enable/disable
> dpdk_qat
> -
> -Upstream-Status: Inappropriate [configuration]
> -
> -Add CONFIG_EXAMPLE_DPDK_QAT to control compilation of dpdk_qat
> -example by PACKAGECONFIG
> -
> -Signed-off-by: Anuj Mittal 
> 
> - examples/Makefile |2 +-
> - 1 file changed, 1 insertion(+), 1 deletion(-)
> -
> -diff --git a/examples/Makefile b/examples/Makefile
> -index b4eddbd..1bc14b0 100644
>  a/examples/Makefile
> -+++ b/examples/Makefile
> -@@ -41,7 +41,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += bond
> - DIRS-y += cmdline
> - DIRS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += distributor
> - ifneq ($(ICP_ROOT),)
> --DIRS-y += dpdk_qat
> -+DIRS-$(CONFIG_EXAMPLE_DPDK_QAT) += dpdk_qat
> - endif
> - DIRS-y += exception_path
> - DIRS-y += helloworld
> --- 
> -1.7.9.5
> -
> diff --git a/common/recipes-extended/dpdk/dpdk/dpdk-16.04-point-to-
> the-right-include-and-lib-path.patch b/common/recipes-
> extended/dpdk/dpdk/dpdk-16.04-point-to-the-right-include-and-lib-
> path.patch
> deleted file mode 100644
> index 75bb517..000
> --- a/common/recipes-extended/dpdk/dpdk/dpdk-16.04-point-to-the-
> right-include-and-lib-path.patch
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -From 928595c80ae28d19861d7e76ed898a8fb3f2c1dc Mon Sep 17 00:00:00
> 2001
> -From: Anuj Mittal 
> -Date: Fri, 24 Jul 2015 23:57:17 +0800
> -Subject: [PATCH] dpdk: point to the right include and lib path
> -
> -Upstream-Status: Inappropriate [Configuration]
> -
> -Make sure that we point to the right location of qat
> -lac headers and library.
> -
> -Signed-off-by: Anuj Mittal 
> 
> - examples/dpdk_qat/Makefile |7 ++-
> 

Re: [meta-intel] [PATCH] cryptodev-module: update 0001-zc-Force-4.10-get_user_pages_remote-API.patch

[Wold, Saul]

On Thu, 2017-07-20 at 00:09 +, Wold, Saul wrote:
> On Wed, 2017-07-12 at 19:42 -0700, Robert Yang wrote:
> > 
> > Update it for cryptodev-module 1.9.
> > 
> 
> Not sure what happened, but I am getting the following failures in
> the
> World build.  I seem to be OK building this on a local machine.
> 
> http://yocto-ab-master.jf.intel.com:8012/builders/nightly-meta-intel-
> wo
> rld/builds/9/steps/BuildImages_1/logs/stdio
> 
This may not be accessible, so here is the actual error:


ERROR: cryptodev-module-1.8-r0 do_patch: Command Error: 'quilt --
quiltrc /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-meta-
intel-world/build/build/tmp/work/intel_corei7_64-poky-linux/cryptodev-
module/1.8-r0/recipe-sysroot-native/etc/quiltrc push' exited with
0  Output:
Applying patch 0001-zc-Force-4.10-get_user_pages_remote-API.patch
patching file zc.c
Hunk #1 FAILED at 65.
1 out of 1 hunk FAILED -- rejects in file zc.c
Patch 0001-zc-Force-4.10-get_user_pages_remote-API.patch does not apply
(enforce with -f)
ERROR: cryptodev-module-1.8-r0 do_patch: Function failed:
patch_do_patch
ERROR: Logfile of failure stored in: /home/pokybuild/yocto-
autobuilder/yocto-worker/nightly-meta-intel-
world/build/build/tmp/work/intel_corei7_64-poky-linux/cryptodev-
module/1.8-r0/temp/log.do_patch.138982
NOTE: recipe cryptodev-module-1.8-r0: task do_patch: Failed
ERROR: Task (/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-
meta-intel-world/build/meta/recipes-kernel/cryptodev/cryptodev-
module_1.8.bb:do_patch) failed with exit code '1'
> Can you please take a quick look?
> 
> Sau!
> 
> > 
> > Signed-off-by: Robert Yang <liezhi.y...@windriver.com>
> > ---
> >  .../0001-zc-Force-4.10-get_user_pages_remote-API.patch  | 13
> > +
> >  1 file changed, 5 insertions(+), 8 deletions(-)
> > 
> > diff --git a/common/recipes-kernel/cryptodev/cryptodev-module/0001-
> > zc-Force-4.10-get_user_pages_remote-API.patch b/common/recipes-
> > kernel/cryptodev/cryptodev-module/0001-zc-Force-4.10-
> > get_user_pages_remote-API.patch
> > index 6722b8c..353126f 100644
> > --- a/common/recipes-kernel/cryptodev/cryptodev-module/0001-zc-
> > Force-
> > 4.10-get_user_pages_remote-API.patch
> > +++ b/common/recipes-kernel/cryptodev/cryptodev-module/0001-zc-
> > Force-
> > 4.10-get_user_pages_remote-API.patch
> > @@ -12,18 +12,15 @@ Signed-off-by: Saul Wold <s...@linux.intel.com>
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >  
> >  diff --git a/zc.c b/zc.c
> > -index 2f4ea99..fcd0669 100644
> > +index ae464ff..b2759ce 100644
> >  --- a/zc.c
> >  +++ b/zc.c
> > -@@ -67,7 +67,7 @@ int __get_userbuf(uint8_t __user *addr, uint32_t
> > len, int write,
> > +@@ -65,7 +65,7 @@ int __get_userbuf(uint8_t __user *addr, uint32_t
> > len, int write,
> > + #elif (LINUX_VERSION_CODE < KERNEL_VERSION(4, 9, 0))
> >     ret = get_user_pages_remote(task, mm,
> >     (unsigned long)addr, pgcount, write, 0,
> > pg,
> > NULL);
> > - #  else
> > --#if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0))
> > -+#if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0) & 0)
> > +-#elif (LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0))
> > ++#elif (LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0) & 0)
> >     ret = get_user_pages_remote(task, mm,
> >     (unsigned long)addr, pgcount, write ?
> > FOLL_WRITE : 0,
> >     pg, NULL);
> > --- 
> > -2.7.4
> > -
> > -- 
> > 2.10.2
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] cryptodev-module: update 0001-zc-Force-4.10-get_user_pages_remote-API.patch

[Wold, Saul]

On Wed, 2017-07-12 at 19:42 -0700, Robert Yang wrote:
> Update it for cryptodev-module 1.9.
> 

Not sure what happened, but I am getting the following failures in the
World build.  I seem to be OK building this on a local machine.

http://yocto-ab-master.jf.intel.com:8012/builders/nightly-meta-intel-wo
rld/builds/9/steps/BuildImages_1/logs/stdio

Can you please take a quick look?

Sau!

> Signed-off-by: Robert Yang 
> ---
>  .../0001-zc-Force-4.10-get_user_pages_remote-API.patch  | 13
> +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/common/recipes-kernel/cryptodev/cryptodev-module/0001-
> zc-Force-4.10-get_user_pages_remote-API.patch b/common/recipes-
> kernel/cryptodev/cryptodev-module/0001-zc-Force-4.10-
> get_user_pages_remote-API.patch
> index 6722b8c..353126f 100644
> --- a/common/recipes-kernel/cryptodev/cryptodev-module/0001-zc-Force-
> 4.10-get_user_pages_remote-API.patch
> +++ b/common/recipes-kernel/cryptodev/cryptodev-module/0001-zc-Force-
> 4.10-get_user_pages_remote-API.patch
> @@ -12,18 +12,15 @@ Signed-off-by: Saul Wold 
>   1 file changed, 1 insertion(+), 1 deletion(-)
>  
>  diff --git a/zc.c b/zc.c
> -index 2f4ea99..fcd0669 100644
> +index ae464ff..b2759ce 100644
>  --- a/zc.c
>  +++ b/zc.c
> -@@ -67,7 +67,7 @@ int __get_userbuf(uint8_t __user *addr, uint32_t
> len, int write,
> +@@ -65,7 +65,7 @@ int __get_userbuf(uint8_t __user *addr, uint32_t
> len, int write,
> + #elif (LINUX_VERSION_CODE < KERNEL_VERSION(4, 9, 0))
>   ret = get_user_pages_remote(task, mm,
>   (unsigned long)addr, pgcount, write, 0, pg,
> NULL);
> - #  else
> --#if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0))
> -+#if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0) & 0)
> +-#elif (LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0))
> ++#elif (LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0) & 0)
>   ret = get_user_pages_remote(task, mm,
>   (unsigned long)addr, pgcount, write ?
> FOLL_WRITE : 0,
>   pg, NULL);
> --- 
> -2.7.4
> -
> -- 
> 2.10.2
> 
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [meta-intel LMS][PATCHV3] Added 0003-Fix-device-file-referance-to-dev-mei0-remove-select.patch patch.

[Wold, Saul]

Anand,

I am sorry, I am going to have to reject this again, you did not
provide a properly formatted main commit message to the patch.

Again, please review: https://www.openembedded.org/wiki/Commit_Patch_Me
ssage_Guidelines

The commit message subject is poorly formatted and a one-line commit
message is not acceptable, please say WHY this patch is needed, this
can be a summary of the LMS patch commit message below.

Thanks

Sau!



On Fri, 2017-07-07 at 17:22 -0700, Anand Vastrad wrote:
> Signed-off-by: Anand Vastrad 
> ---
>  ...-file-referance-to-dev-mei0-remove-select.patch | 91
> ++
>  common/recipes-bsp/amt/lms8_8.0.0-7.bb |  1 +
>  2 files changed, 92 insertions(+)
>  create mode 100644 common/recipes-bsp/amt/lms/0003-Fix-device-file-
> referance-to-dev-mei0-remove-select.patch
> 
> diff --git a/common/recipes-bsp/amt/lms/0003-Fix-device-file-
> referance-to-dev-mei0-remove-select.patch b/common/recipes-
> bsp/amt/lms/0003-Fix-device-file-referance-to-dev-mei0-remove-
> select.patch
> new file mode 100644
> index 000..433d301
> --- /dev/null
> +++ b/common/recipes-bsp/amt/lms/0003-Fix-device-file-referance-to-
> dev-mei0-remove-select.patch
> @@ -0,0 +1,91 @@
> +Fix device file referance to /dev/mei0, remove select post write.
> +
> +LMS uses /dev/mei character device which is absent on current kernel
> versions causing LMS fail to initialize. LMS sends messages to MEI
> with a post select timeout. Select timeout causes SendMessage to fail
> causing LMS to not to communicate properly with MEI.
> +
> +Adding /dev/mei0 device file reference to check first and then
> /dev/mei sucessfully initializes LMS. Rely on write return length and
> remove select with timeout to fix communication with MEI.
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Anand Vastrad 
> +---
> + src/mei/MEILinux.cpp | 43 +++
> 
> + 1 file changed, 7 insertions(+), 36 deletions(-)
> +
> +diff --git a/src/mei/MEILinux.cpp b/src/mei/MEILinux.cpp
> +index 1e9d28f..6d23f54 100755
> +--- a/src/mei/MEILinux.cpp
>  b/src/mei/MEILinux.cpp
> +@@ -94,13 +94,17 @@ bool MEILinux::Init(unsigned char
> reqProtocolVersion)
> + Deinit();
> + }
> + 
> +-_fd = open("/dev/mei", O_RDWR);
> ++_fd = open("/dev/mei0", O_RDWR);
> + 
> + if (_fd == -1 ) {
> + if (_verbose) {
> +-fprintf(stderr, "Error: Cannot establish a
> handle to the MEI driver\n");
> ++fprintf(stderr, "Warning: Cannot establish
> a handle to the MEI driver mei0, retrying with mei \n");
> ++}
> ++_fd = open("/dev/mei", O_RDWR);
> ++if (_fd == -1 ) {
> ++fprintf(stderr, "Error: Cannot establish a
> handle to the MEI driver mei\n");
> ++return false;
> + }
> +-return false;
> + }
> + _initialized = true;
> + 
> +@@ -181,13 +185,7 @@ int MEILinux::ReceiveMessage(unsigned char
> *buffer, int len, unsigned long timeo
> + int MEILinux::SendMessage(const unsigned char *buffer, int len,
> unsigned long timeout)
> + {
> + int rv = 0;
> +-int return_length =0;
> + int error = 0;
> +-fd_set set;
> +-struct timeval tv;
> +-
> +-tv.tv_sec =  timeout / 1000;
> +-tv.tv_usec =(timeout % 1000) * 100;
> + 
> + if (_verbose) {
> + fprintf(stdout, "call write length = %d\n", len);
> +@@ -198,35 +196,8 @@ int MEILinux::SendMessage(const unsigned char
> *buffer, int len, unsigned long ti
> + if (_verbose) {
> + fprintf(stderr,"write failed with status %d
> %d\n", rv, error);
> + }
> +-goto out;
> +-}
> +-
> +-return_length = rv;
> +-
> +-FD_ZERO();
> +-FD_SET(_fd, );
> +-rv = select(_fd+1 ,, NULL, NULL, );
> +-if (rv > 0 && FD_ISSET(_fd, )) {
> +-if (_verbose) {
> +-fprintf(stderr, "write success\n");
> +-}
> + }
> +-else if (rv == 0) {
> +-if (_verbose) {
> +-fprintf(stderr, "write failed on timeout
> with status\n");
> +-}
> +-goto out;
> +-}
> +-else { //rv<0
> +-if (_verbose) {
> +-fprintf(stderr, "write failed on select
> with status %d\n", rv);
> +-}
> +-goto out;
> +-}
> +-
> +-rv = return_length;
> + 
> +-out:
> + if (rv < 0) {
> + Deinit();
> + }
> +-- 
> +2.7.4
> +
> diff --git a/common/recipes-bsp/amt/lms8_8.0.0-7.bb b/common/recipes-
> bsp/amt/lms8_8.0.0-7.bb
> index 842e34a..145b307 100644
> --- a/common/recipes-bsp/amt/lms8_8.0.0-7.bb
> +++ b/common/recipes-bsp/amt/lms8_8.0.0-7.bb
> @@ -12,6 +12,7 @@ SRC_URI = "http://software.intel.com/sites/default/
> files/${BPN}-${PV}.tar.gz \
> file://0001-Protocol.cpp-Add-whitespace-for-gcc6-compile-

Re: [meta-intel] [meta-intel LMS][PATCHV2 1/2] Fix device file referance to /dev/mei0 and remove select post write.

[Wold, Saul]

Well, sorry, but this is also not correct!  

This commit message needs to be inside the patch you are creating below
and the this along with 2/2 should be 1 patch.

You can then submit this as you did the first version.  Again, please
review the wiki links I sent you.

See below in the .patch diff

Sau!



On Fri, 2017-07-07 at 11:34 -0700, Anand Vastrad wrote:
> LMS uses /dev/mei character device which is absent on current kernel
> versions causing LMS fail to initialize. LMS sends messages to MEI
> with a post select timeout. Select timeout causes SendMessage to fail
> causing LMS to not to communicate properly with MEI.
> 
> Adding /dev/mei0 device file reference to check first and then
> /dev/mei sucessfully initializes LMS. Rely on write return length and
> remove select with timeout to fix communication with MEI.
> 
> Upstream-Status: Submitted [meta-intel@yoctoproject.org]
> 
> Signed-off-by: Anand Vastrad 
> ---
>  .../amt/lms/0003-device-file-reference-fix.patch   | 73
> ++
>  1 file changed, 73 insertions(+)
>  create mode 100644 common/recipes-bsp/amt/lms/0003-device-file-
> reference-fix.patch
> 
> diff --git a/common/recipes-bsp/amt/lms/0003-device-file-reference-
> fix.patch b/common/recipes-bsp/amt/lms/0003-device-file-reference-
> fix.patch
> new file mode 100644
> index 000..0269438
> --- /dev/null
> +++ b/common/recipes-bsp/amt/lms/0003-device-file-reference-fix.patch
> @@ -0,0 +1,73 @@

You need the above commit message here, however you create your patches
for LMS, you need the above commit message here.

> +--- lms8_8.0.0-7.orig/src/mei/MEILinux.cpp   2012-10-11
> 05:16:05.0 -0700
>  lms8_8.0.0-7/src/mei/MEILinux.cpp2017-06-21
> 15:14:13.725853901 -0700
> +@@ -94,13 +94,17 @@
> + Deinit();
> + }
> +
> +-_fd = open("/dev/mei", O_RDWR);
> ++_fd = open("/dev/mei0", O_RDWR);
> +
> + if (_fd == -1 ) {
> + if (_verbose) {
> +-fprintf(stderr, "Error: Cannot establish a
> handle to the MEI driver\n");
> ++fprintf(stderr, "Warning: Cannot establish
> a handle to the MEI driver mei0, retrying with mei \n");
> ++}
> ++_fd = open("/dev/mei", O_RDWR);
> ++if (_fd == -1 ) {
> ++fprintf(stderr, "Error: Cannot establish a
> handle to the MEI driver mei\n");
> ++return false;
> + }
> +-return false;
> + }
> + _initialized = true;
> +
> +@@ -181,13 +185,7 @@
> + int MEILinux::SendMessage(const unsigned char *buffer, int len,
> unsigned long timeout)
> + {
> + int rv = 0;
> +-int return_length =0;
> + int error = 0;
> +-fd_set set;
> +-struct timeval tv;
> +-
> +-tv.tv_sec =  timeout / 1000;
> +-tv.tv_usec =(timeout % 1000) * 100;
> +
> + if (_verbose) {
> + fprintf(stdout, "call write length = %d\n", len);
> +@@ -198,35 +196,8 @@
> + if (_verbose) {
> + fprintf(stderr,"write failed with status %d
> %d\n", rv, error);
> + }
> +-goto out;
> +-}
> +-
> +-return_length = rv;
> +-
> +-FD_ZERO();
> +-FD_SET(_fd, );
> +-rv = select(_fd+1 ,, NULL, NULL, );
> +-if (rv > 0 && FD_ISSET(_fd, )) {
> +-if (_verbose) {
> +-fprintf(stderr, "write success\n");
> +-}
> + }
> +-else if (rv == 0) {
> +-if (_verbose) {
> +-fprintf(stderr, "write failed on timeout
> with status\n");
> +-}
> +-goto out;
> +-}
> +-else { //rv<0
> +-if (_verbose) {
> +-fprintf(stderr, "write failed on select
> with status %d\n", rv);
> +-}
> +-goto out;
> +-}
> +-
> +-rv = return_length;
> +
> +-out:
> + if (rv < 0) {
> + Deinit();
> + }
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] Yocto meta-intel LMS patch:

[Wold, Saul]

Please review the 

https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
 
and 

https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

On how to properly submit a patch to meta-intel@yoctoproject.org.

This is not correctly formatted and the internal 0003* patch does not
contain a properly formatted commit message with Upsteam-Status: and
Signed-off-by:

Please correct this and re-submit.

Sau!
 
On Thu, 2017-07-06 at 23:12 +, Vastrad, Anand wrote:
> Hi meta-intel@yocto
>  
> LMS8 is currently broken on meta-intel Yocto repository. Attached
> patch(same as below plain text) gets LMS8 working on meta-intel
> Yocto.
> Please pick this patch into meta-intel Yocto.
>  
> Thanks,
> Anand Vastrad
> ---
> ---
>  
> Added /dev/mei0 device file reference. Fix select timeout on
> SendMessage.
>  
> LMS uses /dev/mei character device which is absent on current kernel
> versions causing LMS fail to initialize. LMS sends messages to MEI
> with a post select timeout. Select timeout causes SendMessage to fail
> causing LMS to not to communicate properly with MEI.
>  
> Adding /dev/mei0 device file reference to check first and then
> /dev/mei sucessfully initializes LMS. Rely on write return length and
> remove select with timeout to fix communication with MEI.
>  
> Signed-off-by: Anand Vishwanath Vastrad 
>  
> diff --git a/common/recipes-bsp/amt/lms/0003-device-file-reference-
> fix.patch b/common/recipes-bsp/amt/lms/0003-device-file-reference-
> fix.patch
> new file mode 100644
> index 000..d616731
> --- /dev/null
> +++ b/common/recipes-bsp/amt/lms/0003-device-file-reference-fix.patch
> @@ -0,0 +1,73 @@
> +--- lms8_8.0.0-7.orig/src/mei/MEILinux.cpp 2012-10-11
> 05:16:05.0 -0700
>  lms8_8.0.0-7/src/mei/MEILinux.cpp 2017-06-21 15:14:13.725853901
> -0700
> +@@ -94,13 +94,17 @@
> +  Deinit();
> +    }
> +
> +-   _fd = open("/dev/mei", O_RDWR);
> ++   _fd = open("/dev/mei0", O_RDWR);
> +
> +    if (_fd == -1 ) {
> +  if (_verbose) {
> +-  fprintf(stderr, "Error: Cannot establish a handle to
> the MEI driver\n");
> ++  fprintf(stderr, "Warning: Cannot establish a handle
> to the MEI driver mei0, retrying with mei \n");
> ++ }
> ++ _fd = open("/dev/mei", O_RDWR);
> ++ if (_fd == -1 ) {
> ++  fprintf(stderr, "Error: Cannot establish a handle to
> the MEI driver mei\n");
> ++  return false;
> +  }
> +- return false;
> +    }
> +    _initialized = true;
> +
> +@@ -181,13 +185,7 @@
> + int MEILinux::SendMessage(const unsigned char *buffer, int len,
> unsigned long timeout)
> + {
> +    int rv = 0;
> +-   int return_length =0;
> +    int error = 0;
> +-   fd_set set;
> +-   struct timeval tv;
> +-
> +-   tv.tv_sec =  timeout / 1000;
> +-   tv.tv_usec =(timeout % 1000) * 100;
> +
> +    if (_verbose) {
> +  fprintf(stdout, "call write length = %d\n", len);
> +@@ -198,35 +196,8 @@
> +  if (_verbose) {
> +   fprintf(stderr,"write failed with status %d %d\n",
> rv, error);
> +  }
> +- goto out;
> +-   }
> +-
> +-   return_length = rv;
> +-
> +-   FD_ZERO();
> +-   FD_SET(_fd, );
> +-   rv = select(_fd+1 ,, NULL, NULL, );
> +-   if (rv > 0 && FD_ISSET(_fd, )) {
> +- if (_verbose) {
> +-  fprintf(stderr, "write success\n");
> +- }
> +    }
> +-   else if (rv == 0) {
> +- if (_verbose) {
> +-  fprintf(stderr, "write failed on timeout with
> status\n");
> +- }
> +- goto out;
> +-   }
> +-   else { //rv<0
> +- if (_verbose) {
> +-  fprintf(stderr, "write failed on select with status
> %d\n", rv);
> +- }
> +- goto out;
> +-   }
> +-
> +-   rv = return_length;
> +
> +-out:
> +    if (rv < 0) {
> +  Deinit();
> +    }
> diff --git a/common/recipes-bsp/amt/lms8_8.0.0-7.bb b/common/recipes-
> bsp/amt/lms8_8.0.0-7.bb
> index 842e34a..e50b3e8 100644
> --- a/common/recipes-bsp/amt/lms8_8.0.0-7.bb
> +++ b/common/recipes-bsp/amt/lms8_8.0.0-7.bb
> @@ -12,6 +12,7 @@ SRC_URI = "http://software.intel.com/sites/default/
> files/${BPN}-${PV}.tar.gz \
>     file://0001-Protocol.cpp-Add-whitespace-for-gcc6-compile-
> error.patch \
>     file://0001-Include-sys-select.h-for-fd_set.patch \
>     file://0002-Use-proper-netinet-in.h-API.patch \
> +   file://0003-device-file-reference-fix.patch \
>     "
>  COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
>  
>  
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH V2] libyami: Update to 1.2.0

[Wold, Saul]

My bad, I was looking on the wrong branch, I have this updated version
and willbe running it on the AB here shortly.

Sorry for the noise.

Sau!

On Tue, 2017-06-20 at 10:22 -0700, Saul Wold wrote:
> On Mon, 2017-06-19 at 08:00 -0700, Khem Raj wrote:
> > 
> > Use downloadfilename fetcher option to avoid
> > DL_DIR conflicts since both libyami and libyami-utils
> > name the tarballs to be PV.tar.gz and PV happens
> > to be same for both
> > 
> Since I already merged the first version, can you provide a rebased
> patch for these changes.
> 
> Sau!
> 
> > 
> > Signed-off-by: Khem Raj 
> > ---
> >  .../libyami/{libyami-utils_1.1.0.bb => libyami-utils_1.2.0.bb}   | 
> > 9
> > +++--
> >  .../libyami/{libyami_1.1.0.bb => libyami_1.2.0.bb}   |
> > 9
> > +++--
> >  2 files changed, 6 insertions(+), 12 deletions(-)
> >  rename common/recipes-multimedia/libyami/{libyami-utils_1.1.0.bb
> > =>
> > libyami-utils_1.2.0.bb} (83%)
> >  mode change 100755 => 100644
> >  rename common/recipes-multimedia/libyami/{libyami_1.1.0.bb =>
> > libyami_1.2.0.bb} (74%)
> >  mode change 100755 => 100644
> > 
> > diff --git a/common/recipes-multimedia/libyami/libyami-
> > utils_1.1.0.bb 
> > b/common/recipes-multimedia/libyami/libyami-utils_1.2.0.bb
> > old mode 100755
> > new mode 100644
> > similarity index 83%
> > rename from common/recipes-multimedia/libyami/libyami-
> > utils_1.1.0.bb
> > rename to common/recipes-multimedia/libyami/libyami-utils_1.2.0.bb
> > index 4c1dceb..0cda668
> > --- a/common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb
> > +++ b/common/recipes-multimedia/libyami/libyami-utils_1.2.0.bb
> > @@ -7,12 +7,9 @@ BUGTRACKER = "https://github.com/01org/libyami-uti
> > ls
> > /issues/new"
> >  LICENSE = "Apache-2.0"
> >  LIC_FILES_CHKSUM =
> > "file://LICENSE;md5=e3fc50a88d0a364313df4b21ef20c29e"
> >  
> > -SRC_URI = "https://github.com/01org/libyami-utils/archive/${PV}.ta
> > r.
> > gz"
> > -
> > -SRC_URI[md5sum] = "7473e643e09296c20ed1286743906004"
> > -SRC_URI[sha256sum] =
> > "66865408b63d09a80f1305828898c9cb5e7d57585b944b08148c92d774ba8dcd"
> > -
> > -S = "${WORKDIR}/libyami-utils-${PV}"
> > +SRC_URI = "https://github.com/01org/libyami-utils/archive/${PV}.ta
> > r.
> > gz;downloadfilename=${BP}.tar.gz"
> > +SRC_URI[md5sum] = "b4637f1a384e3de20076bf01ca2515d3"
> > +SRC_URI[sha256sum] =
> > "3dbaedc797bf2d0e03879bfdbea462c3ec2aac89b49c1ed55cbff1be2590d1e8"
> >  
> >  DEPENDS = "libva libyami"
> >  
> > diff --git a/common/recipes-multimedia/libyami/libyami_1.1.0.bb
> > b/common/recipes-multimedia/libyami/libyami_1.2.0.bb
> > old mode 100755
> > new mode 100644
> > similarity index 74%
> > rename from common/recipes-multimedia/libyami/libyami_1.1.0.bb
> > rename to common/recipes-multimedia/libyami/libyami_1.2.0.bb
> > index 8efd6f9..fa468b2
> > --- a/common/recipes-multimedia/libyami/libyami_1.1.0.bb
> > +++ b/common/recipes-multimedia/libyami/libyami_1.2.0.bb
> > @@ -6,14 +6,11 @@ HOMEPAGE = "https://github.com/01org/libyami;
> >  BUGTRACKER = "https://github.com/01org/libyami/issues/new;
> >  
> >  LICENSE = "Apache-2.0"
> > -SRC_URI = "https://github.com/01org/libyami/archive/libyami-${PV}.
> > ta
> > r.gz"
> > -
> >  LIC_FILES_CHKSUM =
> > "file://COPYING.LIB;md5=3b83ef96387f14655fc854ddc3c6bd57"
> >  
> > -SRC_URI[md5sum] = "4e949cca98be87855f68af987c1eba3f"
> > -SRC_URI[sha256sum] =
> > "08acb7857a1a85c1d3341862d6b523c0eb1603adee454469cda765b6bf04f614"
> > -
> > -S = "${WORKDIR}/libyami-libyami-${PV}"
> > +SRC_URI = "https://github.com/01org/libyami/archive/${PV}.tar.gz;d
> > ow
> > nloadfilename=${BP}.tar.gz"
> > +SRC_URI[md5sum] = "2e2ed3bd900866476eced140799ee48b"
> > +SRC_URI[sha256sum] =
> > "fdc3025f828c065a4434e73f5629e7ab8af593f1abbe097449dd5a13fa7d465f"
> >  
> >  PACKAGECONFIG ??= "${@bb.utils.contains("DISTRO_FEATURES", "x11",
> > "x11", "", d)}"
> >  PACKAGECONFIG[x11] = "--enable-x11,--disable-x11,virtual/libx11
> > libxrandr libxrender"
-- 
___
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

[Wold, Saul]

On Mon, 2017-06-19 at 13:19 +0200, Patrick Ohly wrote:
> On Wed, 2017-06-14 at 18:47 -0700, 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.
> 
> As I was the one who proposed the syntax above, I should refrain from
> commenting on it ;-} Someone else should say "yay" or "nay".
> 
I generally agree with this syntax it's succinct and models RE syntax

> Regarding the code, I think this is something that should be
> submitted
> upstream once we agree that we want this. The code review and perhaps
> even merging can happen upstream.
> 
Agreed, it would be nice for upstream also, but should not block the
implementation and usage here in meta-intel (or maybe in OE).  I guess
that's another discussion point.

Sau!
> -- 
> Best Regards, Patrick Ohly
> 
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
> 
> 
> 
-- 
___
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

[Wold, Saul]

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?

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

[meta-intel] CCB Approval Request for Meta-Intel

[Wold, Saul]

Meta-Intel BSP Team:

Attached is the QA report for the meta-intel 7.0 release for Yocto
Project 2.3.

Based on the report and review of the outstanding and new bugs, I am
going to have the release team complete the release process on Tuesday,
unless I hear a negative response.

I have closed the Cherry Hill/4.1 Race bug as wont fix due to it being
on older non-public hardware and we could not reproduce it on any
released hardware with similar CPU.

Silence is approval!

Sau!


On Thu, 2017-05-25 at 12:23 +, Perez Carranza, Jose wrote:
> Hello All,
>  
> Here is the report for the Meta-Intel Full QA Cycle on Release 2.3
> rc4
>  
> Full Report : https://wiki.yoctoproject.org/wiki/WW21_-_2017-05-22_-_
> Full_Test_Cycle_-_2.3_rc4_-_meta-intel
>  
>  Summary 
>  
> The QA cycle for release 2.3 rc4 Meta-Intel is complete, 2 new bugs
> were found on LSB image for intel-corei7-64 on NUC, one related to
> parselogs failures (11569) and another one to logrotate failure
> (11568), previous issue (11512) found on  rc1 is still present but a
> test matrix will be reviewed to determine if this is problem with the
> specific HW where this is validated so is not a release blocker.
>  
> ==
>  
>  Details 
> Bugs
>    * New
>   o  11568 - [Test Case 1542] test_2_logrotate fails in NUC
> with lsb-image [1]
>   o  11569 - [Test Case 1059] Parselogs is failing to send
> firmware data on corei7-64 LSB image in NUC [2]
>  
>    * Not New
>   o  11512 -  LSB image failed to boot in Cherry Hill
> platform [3]
>   o  9267  - test_parselogs
> (oeqa.runtime.parselogs.ParseLogsTest) failed on NUC 6i5SYH, firmware
> load for i915/skl_guc_ver4.bin failed [4]
>   o  10110 - parselogs/intel-core-i7-64 on cherryhill /irq
> stat interface fatal error/failed to enable keyboard [5]
>   o  10455 - [Test Case 1059] Parselogs is failing on
> genericx86 (32 and 64 bits) giving error: blk_update_request: I/O
> error, dev loop0 [6]
>     
>  
> Full list of bugs can be found at : https://wiki.yoctoproject.org/wik
> i/WW21_-_2017-05-22_-_Full_Test_Cycle_-_2.3_rc4_-_meta-
> intel#Summary_Report
>  
> ==
>  
>  Links =
>  
> 1 – https://bugzilla.yoctoproject.org/show_bug.cgi?id=11560 
> 2 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=11569 
> 3 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=11311 
> 4 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=11512 
> 5 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=9267 
> 6 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=10110 
> 7 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=10455 
>  
> ==
>  
>  
> Regards,
> José
>  
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] BSP QA Test Report for Meta-Intel Release 2.3 rc4

[Wold, Saul]

Stephen,

I have reviewed the open bugs and closed the Cherry Hill/4.1 Race bug
as wont fix due to it being on older non-public hardware.

I am ready to release this if we do not need a CCB, otherwise please
start the CCB process for meta-intel release.

Sau!

On Thu, 2017-05-25 at 12:23 +, Perez Carranza, Jose wrote:
> Hello All,
>  
> Here is the report for the Meta-Intel Full QA Cycle on Release 2.3
> rc4
>  
> Full Report : https://wiki.yoctoproject.org/wiki/WW21_-_2017-05-22_-_
> Full_Test_Cycle_-_2.3_rc4_-_meta-intel
>  
>  Summary 
>  
> The QA cycle for release 2.3 rc4 Meta-Intel is complete, 2 new bugs
> were found on LSB image for intel-corei7-64 on NUC, one related to
> parselogs failures (11569) and another one to logrotate failure
> (11568), previous issue (11512) found on  rc1 is still present but a
> test matrix will be reviewed to determine if this is problem with the
> specific HW where this is validated so is not a release blocker.
>  
> ==
>  
>  Details 
> Bugs
>    * New
>   o  11568 - [Test Case 1542] test_2_logrotate fails in NUC
> with lsb-image [1]
>   o  11569 - [Test Case 1059] Parselogs is failing to send
> firmware data on corei7-64 LSB image in NUC [2]
>  
>    * Not New
>   o  11512 -  LSB image failed to boot in Cherry Hill
> platform [3]
>   o  9267  - test_parselogs
> (oeqa.runtime.parselogs.ParseLogsTest) failed on NUC 6i5SYH, firmware
> load for i915/skl_guc_ver4.bin failed [4]
>   o  10110 - parselogs/intel-core-i7-64 on cherryhill /irq
> stat interface fatal error/failed to enable keyboard [5]
>   o  10455 - [Test Case 1059] Parselogs is failing on
> genericx86 (32 and 64 bits) giving error: blk_update_request: I/O
> error, dev loop0 [6]
>     
>  
> Full list of bugs can be found at : https://wiki.yoctoproject.org/wik
> i/WW21_-_2017-05-22_-_Full_Test_Cycle_-_2.3_rc4_-_meta-
> intel#Summary_Report
>  
> ==
>  
>  Links =
>  
> 1 – https://bugzilla.yoctoproject.org/show_bug.cgi?id=11560 
> 2 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=11569 
> 3 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=11311 
> 4 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=11512 
> 5 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=9267 
> 6 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=10110 
> 7 - https://bugzilla.yoctoproject.org/show_bug.cgi?id=10455 
>  
> ==
>  
>  
> Regards,
> José
>  
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] libyami: Add PACKAGECONFIG for x11

[Wold, Saul]

On Wed, 2017-04-12 at 11:36 +0300, Jussi Kukkonen wrote:
> Without this the recipe fails to build without x11, breaking world
> build.
> 
> Signed-off-by: Jussi Kukkonen 
> ---
>  common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb 
> b/common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb
> index c61fec8..64f8850 100755
> --- a/common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb
> +++ b/common/recipes-multimedia/libyami/libyami-utils_1.1.0.bb
> @@ -18,4 +18,10 @@ DEPENDS = "libva libyami"
>  
>  EXTRA_OECONF = " --enable-tests-gles --disable-md5"
>  
> +PACKAGECONFIG = "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
> +
> +# --enable-x11 needs libva-x11
> +# gles-tests fail to build without x11: see https://github.com/01org
> /libyami-utils/issues/91
> +PACKAGECONFIG[x11] = "--enable-x11 --enable-tests-gles,--disable-x11 
> --disable-tests-gles, virtual/libx11"
> +
>  inherit autotools pkgconfig

This patch does not apply cleanly to master, please verify you have the
current master.

Thanks
   Sau!

> -- 
> 2.1.4
> 
-- 
___
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

[Wold, Saul]

On Wed, 2017-03-22 at 09:49 +0200, Mikko Ylinen wrote:
> 
> On 21/03/17 20:08, Wold, Saul wrote:
> > 
> > On Tue, 2017-03-21 at 11:39 +0200, 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.
> > This package is about 900K
> 
> linux-firmware PKGSIZE according to pkgdata is ~86M.
> 
> > 
> > 
> > > 
> > > IMO, there are better places to shave off size of minimal images
> > > than
> > > cutting out hardware support.
> > > 
> > You realize that core-image-minimal goes from 8.7M -> 59M by adding
> > the
> > modules, so there is not other place to shave off size in the
> > minimal
> > image.
> 
> MACHINE_EXTRA_RRECOMMENDS does not affect core-image-minimal
> (MACHINE_ESSENTIAL_* do).
> 
> > 
> > 
> > 40M is in /lib
> > 6.8M in /boot
> > 
> > I think this is a case where the RefKit includes modules but it
> > does
> > not go into meta-intel, this is more of a Distro/Image level choice
> > than a BSP level choice. So this is not a customer BSP in refkit.
> > 
> > 
> 
> The patch tries to make MACHINE_EXTRA_RRECOMMENDS setting more
> consistent
> accross intel-* machines. Jussi has a good point that linux-firmware 
> without kernel-modules
> is pointless.
> 
> IMO, the config choice is whether to install
> MACHINE_EXTRA_RRECOMMENDS 
> or not.
> 
Agreed, I was not actually testing the actual patch (my bad), and the
difference between EXTRA and ESSENTIAL is exactly as mentioned above, I
withdraw my objection to this patch.

Sau!

> -- Mikko
-- 
___
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

[Wold, Saul]

On Tue, 2017-03-21 at 11:39 +0200, 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.

This package is about 900K

> IMO, there are better places to shave off size of minimal images
> than 
> cutting out hardware support.
> 
You realize that core-image-minimal goes from 8.7M -> 59M by adding the
modules, so there is not other place to shave off size in the minimal
image.

40M is in /lib
6.8M in /boot

I think this is a case where the RefKit includes modules but it does
not go into meta-intel, this is more of a Distro/Image level choice
than a BSP level choice. So this is not a customer BSP in refkit.

Sau!



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

Re: [meta-intel] [PATCH] Add thermald to MACHINE_EXTRA_RRECOMMENDS

[Wold, Saul]

On Thu, 2017-03-16 at 17:10 +0200, Jussi Laako wrote:
> On core2-32 and corei7-64, add thermald to MACHINE_EXTRA_RRECOMMENDS.
> 
> Signed-off-by: Jussi Laako 
> ---
>  conf/machine/intel-core2-32.conf  | 2 +-
>  conf/machine/intel-corei7-64.conf | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/conf/machine/intel-core2-32.conf b/conf/machine/intel-
> core2-32.conf
> index c5cfb9c..e58b96e 100644
> --- a/conf/machine/intel-core2-32.conf
> +++ b/conf/machine/intel-core2-32.conf
> @@ -14,7 +14,7 @@ MACHINE_FEATURES += "intel-ucode"
>  
>  MACHINE_HWCODECS ?= "va-intel gstreamer1.0-vaapi"
>  
> -MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"
> +MACHINE_EXTRA_RRECOMMENDS += "linux-firmware thermald"
> 
I wonder if we should move this to the meta-intel-common, should it be
available on a Quark/Galileo platform also?

Sau!

>  
>  MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "gma500-gfx-check"
>  
> diff --git a/conf/machine/intel-corei7-64.conf b/conf/machine/intel-
> corei7-64.conf
> index 43e7c1a..e2ec127 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 += "linux-firmware lms8 thermald"
>  
>  XSERVER ?= "${XSERVER_X86_BASE} \
>  ${XSERVER_X86_EXT} \
> -- 
> 2.11.0
> 
-- 
___
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

[Wold, Saul]

On Mon, 2017-02-27 at 10:11 -0800, Cal Sullivan wrote:
> This one really scares me. Old version, removed CVE fixes, and might
> cause compatibility issues with other layers...
> 
> Saul?
> 
I thought that Alejandro was going to have another series that removed
the binutils?

Alejandro?

There was a presentation that talked about the LTO work at ELC, but
it's still getting pushed.

Sau!

> 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] Does it support i5 too ?

[Wold, Saul]

On Fri, 2017-02-24 at 06:24 +0200, Ran Shalit wrote:
> Hello,
> 
> In meta-intel readme in GIT, I see that it supports:
> 
>  - Intel-core2-32 Intel® Common Core BSP (Intel-core2-32)
>  - Intel-core2-32 Intel® Common Core BSP (Intel-quark)
>  - Intel-corei7-64 Intel® Common Core BSP (Intel-corei7-64)
> 
> I am trying to run the .iso on virtualbox on machine with Intel i5
> core -64 bits:
> model name : Intel(R) Core(TM) i5-6440HQ CPU @ 2.60GHz
> 
> Is it possible to use the iso of meta-intel with i5 ?
> 
The intel-corei7-64 would be appropriate for this, it a new Core CPU vs
Atom CPU and the i7 vs i5 distinction would be related speed and cores.
The CPU tunings are the same for both.

Sau!

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

Re: [meta-intel] [PATCH 0/2] Add RMC support in systemd-boot's EFI stub

[Wold, Saul]

On Fri, 2017-01-27 at 15:35 +0200, Mikko Ylinen wrote:
> This patchset enables to use runtime machine configuration (RMC) in
> systemd-boot's EFI stub too.
> 
> I've been using Minnowboard Turbot boards (in addition to a 'broxton-
> m'
> board) in testing. However, the RMC data for Turbot was missing so
> this
> patchset also adds a fingerprint and a simple cmdline setting for it.
> 
> Mikko Ylinen (2):
>   systemd-boot: use RMC database in EFI stub
>   rmc: add Minnowboard Turbot board data
> 
>  .../rmc/boards/MinnowboardTurbot/KBOOTPARAM|   1 +
>  .../boards/MinnowboardTurbot/minnowboardturbot.fp  | Bin 0 -> 154
> bytes
>  ...Link-RMC-library-into-bootloader-and-stub.patch |  39 ++
>  ...-sd-boot-Link-RMC-library-into-bootloader.patch |  31 
>  ...-kernel-command-line-fragment-in-EFI-stub.patch |  81
> +
>  .../systemd-boot/systemd-boot_%.bbappend   |   3 +-
>  6 files changed, 123 insertions(+), 32 deletions(-)
>  create mode 100644 common/recipes-
> bsp/rmc/boards/MinnowboardTurbot/KBOOTPARAM
>  create mode 100644 common/recipes-
> bsp/rmc/boards/MinnowboardTurbot/minnowboardturbot.fp
>  create mode 100644 common/recipes-bsp/systemd-boot/systemd-
> boot/0001-sd-boot-Link-RMC-library-into-bootloader-and-stub.patch
>  delete mode 100644 common/recipes-bsp/systemd-boot/systemd-
> boot/0001-sd-boot-Link-RMC-library-into-bootloader.patch
>  create mode 100644 common/recipes-bsp/systemd-boot/systemd-
> boot/0004-sd-boot-Support-global-kernel-command-line-fragment-in-EFI-
> stub.patch
> 
> -- 
> 2.11.0
> 
> -
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki 
> Business Identity Code: 0357606 - 4 
> Domiciled in Helsinki 
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
You should really remove this note from patches sent to public mailing
list as it's inappropriate.

Sau!
-- 
___
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

[Wold, Saul]

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?

Sau!

> Signed-off-by: Mikko Ylinen 
> ---
>  ...Link-RMC-library-into-bootloader-and-stub.patch | 39 +++
>  ...-sd-boot-Link-RMC-library-into-bootloader.patch | 31 -
>  ...-kernel-command-line-fragment-in-EFI-stub.patch | 81
> ++
>  .../systemd-boot/systemd-boot_%.bbappend   |  3 +-
>  4 files changed, 122 insertions(+), 32 deletions(-)
>  create mode 100644 common/recipes-bsp/systemd-boot/systemd-
> boot/0001-sd-boot-Link-RMC-library-into-bootloader-and-stub.patch
>  delete mode 100644 common/recipes-bsp/systemd-boot/systemd-
> boot/0001-sd-boot-Link-RMC-library-into-bootloader.patch
>  create mode 100644 common/recipes-bsp/systemd-boot/systemd-
> boot/0004-sd-boot-Support-global-kernel-command-line-fragment-in-EFI-
> stub.patch
> 
> diff --git a/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-
> boot-Link-RMC-library-into-bootloader-and-stub.patch
> b/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-
> library-into-bootloader-and-stub.patch
> new file mode 100644
> index 000..2f248e2
> --- /dev/null
> +++ b/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-
> RMC-library-into-bootloader-and-stub.patch
> @@ -0,0 +1,39 @@
> +From fe1c2fdfe81f2ac2b41fe8543ba07f1911770d26 Mon Sep 17 00:00:00
> 2001
> +From: Jianxun Zhang 
> +Date: Sat, 21 May 2016 18:52:07 -0700
> +Subject: [PATCH] sd-boot: Link RMC library into bootloader and stub
> +
> +Add RMC library into bootloader binary and stub.
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Jianxun Zhang 
> +---
> + Makefile.am | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +
> +diff --git a/Makefile.am b/Makefile.am
> +index 305099ab6..9fb6f9b7b 100644
> +--- a/Makefile.am
>  b/Makefile.am
> +@@ -2802,7 +2802,7 @@ $(top_builddir)/src/boot/efi/%.o:
> $(top_srcdir)/src/boot/efi/%.c $(addprefix $(t
> + 
> + $(systemd_boot_solib): $(systemd_boot_objects)
> + $(AM_V_CCLD)$(LD) $(efi_ldflags) $(systemd_boot_objects) \
> +--o $@ -lefi -lgnuefi $(shell $(CC) -print-libgcc-
> file-name); \
> ++-o $@ -lefi -lgnuefi -lrmcefi $(shell $(CC) -print-
> libgcc-file-name); \
> + nm -D -u $@ | grep ' U ' && exit 1 || :
> + 
> + $(systemd_boot): $(systemd_boot_solib)
> +@@ -2852,7 +2852,7 @@ $(top_builddir)/src/boot/efi/%.o:
> $(top_srcdir)/src/boot/efi/%.c $(addprefix $(t
> + 
> + $(stub_solib): $(stub_objects)
> + $(AM_V_CCLD)$(LD) $(efi_ldflags) $(stub_objects) \
> +--o $@ -lefi -lgnuefi $(shell $(CC) -print-libgcc-
> file-name); \
> ++-o $@ -lefi -lgnuefi -lrmcefi $(shell $(CC) -print-
> libgcc-file-name); \
> + nm -D -u $@ | grep ' U ' && exit 1 || :
> + 
> + $(stub): $(stub_solib)
> +-- 
> +2.11.0
> +
> diff --git a/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-
> boot-Link-RMC-library-into-bootloader.patch b/common/recipes-
> bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-library-into-
> bootloader.patch
> deleted file mode 100644
> index 626efce..000
> --- a/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-
> RMC-library-into-bootloader.patch
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -From 1ccd031ce97501f8ee63f39e8794437d568115dc Mon Sep 17 00:00:00
> 2001
> -From: Jianxun Zhang 
> -Date: Sat, 21 May 2016 18:52:07 -0700
> -Subject: [PATCH 1/3] sd-boot: Link RMC library into bootloader
> -
> -Add RMC library into bootloader binary. EFI stub is not changed
> -until we really need rmc in stub.
> -
> -Upstream-Status: Pending
> -
> -Signed-off-by: Jianxun Zhang 
> 
> - Makefile.am | 2 +-
> - 1 file changed, 1 insertion(+), 1 deletion(-)
> -
> -diff --git a/Makefile.am b/Makefile.am
> -index 305099a..df176a5 100644
>  a/Makefile.am
> -+++ b/Makefile.am
> -@@ -2802,7 +2802,7 @@ $(top_builddir)/src/boot/efi/%.o:
> $(top_srcdir)/src/boot/efi/%.c $(addprefix $(t
> - 
> - $(systemd_boot_solib): $(systemd_boot_objects)
> - $(AM_V_CCLD)$(LD) $(efi_ldflags) $(systemd_boot_objects) \
> ---o $@ -lefi -lgnuefi $(shell $(CC) -print-libgcc-
> file-name); \
> -+-o $@ -lefi -lgnuefi -lrmcefi $(shell $(CC) -print-
> libgcc-file-name); \
> - nm -D -u $@ | grep ' U ' && exit 1 || :
> - 
> - $(systemd_boot): $(systemd_boot_solib)
> --- 
> -2.7.4
> -
> diff --git a/common/recipes-bsp/systemd-boot/systemd-boot/0004-sd-
> 

Re: [meta-intel] OpenCL stalls on Apollo Lake GPU

[Wold, Saul]

Sorry for the delay in getting back to you.


On Mon, 2017-01-16 at 12:27 +, Tony Whittam wrote:
> Hi everyone,
> 
> I don't know if this is too specialised for this list. I was directed
> to the Yocto Resources by Intel Premier Support. Anyway, no harm in
> asking the question :-)
> 
Right, it was a little more complex since the we generally work with
the core BSP, but we want to help just took trying to find the right
people.

> Preamble
> Build: Yocto from the Apollo Lake BSP release gold, 
> Hardware: Oxbow Hill Rev B CRB with Intel Atom E3950 and 4GB DDR3 RAM
> (one SODIMM)
> Build: core-image-sato-sdk
> Installed on the onboard eMMC.
> OpenCL: installed user space drivers from SRB4 https://software.intel
> .com/file/533571/download
> 
Have you looked at the Beignet (https://01.org/beignet)?

I am still tracking information down.

Sau!

> I'm currently evaluating the Apollo Lake platform as a candidate to
> run our embedded application. We already have this application
> running on less powerful ARM based Linux systems with Mali GPU using
> OpenCL 1.2. We're now evaluating the E3950 as a faster alternative.
> To evaluate the application I need OpenCL 1.2 or later.
> 
> To verify the OpenCL installation I have built and run the Intel demo
> apps: CapsBasic and Bitonic Sort. CapsBasic sees two devices: CPU and
> GPU and Bitonic sort can run its kernels correctly on both the CPU
> and the GPU. 
> 
> The issue
> Simply put, the application has 
> thread 1 (feeder): has a loop that feeds data into OpenCL and queues
> kernels
> thread 2 (consumer): waits for results and reads output data. 
> an OpenCL Host command queue with out-of-order execution enabled
> When I run my app and select the GPU OpenCL device, the feeder thread
> stalls inside a blocking call to clEnqueueMapBuffer(). At this point
> only one thing has been queued on the command queue: a buffer unmap
> command for a different buffer. This unmap is waiting for an OpenCL
> event that will indicate data ready to be processed.
> 
> When I run my app and select the CPU OpenCL device, it works
> perfectly.
> 
> Does anyone have any ideas on
> what might be causing this?
> how to debug this on the Yocto platform?
> Best regards,
> 
> Tony
> 
> 
> -- 
> Tony Whittam
> Rapt Touch
> 
> Confidentiality Notice: 
> 
> The information contained in this message, including any attachments
> hereto, may be confidential and is intended to be read only by the
> individual or entity to whom this message is addressed. If the reader
> of this message is not the intended recipient or an agent or designee
> of the intended recipient, please note that any review, use,
> disclosure or distribution of this message or its attachments, in any
> form, is strictly prohibited. If you have received this message in
> error, please immediately notify the sender and/or Rapt Touch Ltd via
> email at i...@rapttouch.com and delete or destroy any copy of this
> message and its attachments.
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] linux-yocto: fix builds for x32

[Wold, Saul]

On Thu, 2016-12-29 at 13:28 -0700, Christopher Larson wrote:
> From: Christopher Larson 
> 
> corei7-64-intel-common overrides are used here, but this isn't in use
> when
> building for x32. Also obey this for corei7-64-x32-intel-common.
> 
> An alternative would be to place this in intel-common-pkgarch.inc,
> where the
> common pkgarch is set up, but that would have higher potential
> impact, being
> global.
> 
> With this fix applied, along with other fixes to oe-core, it's
> possible to get
> successful builds with DEFAULTTUNE set to "corei7-64-x32", and boot
> the
> resulting images for intel-corei7-64.
> 
Chris,

I was actually starting to look at this myself before the break.  Are
the other fixes to OE-Core in or pending?

When I tried this patch I am getting no linux-yocto (or virtual/kernel)
for COMPATIBLE_MACHINE.

Thanks

Sau!

> Signed-off-by: Christopher Larson 
> ---
>  common/recipes-kernel/linux/linux-yocto_%.bbappend | 4 
>  1 file changed, 4 insertions(+)
>  create mode 100644 common/recipes-kernel/linux/linux-
> yocto_%.bbappend
> 
> diff --git a/common/recipes-kernel/linux/linux-yocto_%.bbappend
> b/common/recipes-kernel/linux/linux-yocto_%.bbappend
> new file mode 100644
> index 000..7c29be1
> --- /dev/null
> +++ b/common/recipes-kernel/linux/linux-yocto_%.bbappend
> @@ -0,0 +1,4 @@
> +# The kernel build is 64-bit regardless, so include both common
> overrides.
> +# Without this, the kernel will be missing vars that make it
> buildable for the
> +# intel-corei7-64 machine.
> +MACHINEOVERRIDES_prepend_corei7-64-x32-intel-common = "corei7-64-
> intel-common:"
> -- 
> 2.8.0
> 
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] multimedia recipes: add libyami, intel VA-API Media codecs with hardware acceleration

[Wold, Saul]

On Tue, 2016-12-20 at 20:27 -0500, wudping wrote:
> add libyami_1.0.1.bb and libyami-utils_1.0.1.bb files.
> Yami is core building block for media solution; libyami-utils has
> some Applications
> and Scripts for libyami.
> 
Please split this into 2 patches one for each recipe and correct the
short description to be in the form of

: 



Sau!

> their home websites are:
> libyami: https://github.com/01org/libyami
> libyami-utils: https://github.com/01org/libyami-utils
> 
> Signed-off-by: Xu Guangxin 
> Signed-off-by: wudping 
> ---
>  .../libyami/libyami-utils_1.0.1.bb | 21
> +
>  common/recipes-multimedia/libyami/libyami_1.0.1.bb | 22
> ++
>  2 files changed, 43 insertions(+)
>  create mode 100755 common/recipes-multimedia/libyami/libyami-
> utils_1.0.1.bb
>  create mode 100755 common/recipes-
> multimedia/libyami/libyami_1.0.1.bb
> 
> diff --git a/common/recipes-multimedia/libyami/libyami-utils_1.0.1.bb 
> b/common/recipes-multimedia/libyami/libyami-utils_1.0.1.bb
> new file mode 100755
> index 000..08341f1
> --- /dev/null
> +++ b/common/recipes-multimedia/libyami/libyami-utils_1.0.1.bb
> @@ -0,0 +1,21 @@
> +SUMMARY = "Applications and Scripts for libyami."
> +DESCRIPTION = "Applications and Scripts for libyami."
> +
> +HOMEPAGE = "https://github.com/01org/libyami-utils;
> +BUGTRACKER = "https://github.com/01org/libyami-utils/issues/new;
> +
> +LICENSE = "Apache-2.0"
> +LIC_FILES_CHKSUM =
> "file://LICENSE;md5=e3fc50a88d0a364313df4b21ef20c29e"
> +
> +SRC_URI = "https://github.com/01org/libyami-utils/archive/${PV}.tar.
> gz"
> +
> +SRC_URI[md5sum] = "51420c8ddcecac1e24a238c43e2e18ca"
> +SRC_URI[sha256sum] =
> "a5826a5ade885dc33e1a7d23f5f261522f88661ee486d3b8bbff6bdfaacf2495"
> +
> +S = "${WORKDIR}/libyami-utils-${PV}"
> +
> +DEPENDS = "libva libyami"
> +
> +EXTRA_OECONF = " --enable-tests-gles --disable-md5"
> +
> +inherit autotools pkgconfig
> diff --git a/common/recipes-multimedia/libyami/libyami_1.0.1.bb
> b/common/recipes-multimedia/libyami/libyami_1.0.1.bb
> new file mode 100755
> index 000..c468791
> --- /dev/null
> +++ b/common/recipes-multimedia/libyami/libyami_1.0.1.bb
> @@ -0,0 +1,22 @@
> +SUMMARY = "Yami is media infrastructure base on libva"
> +DESCRIPTION = "Yet Another Media Infrastructure \
> +light weight hardware codec library base on VA-API "
> +
> +HOMEPAGE = "https://github.com/01org/libyami;
> +BUGTRACKER = "https://github.com/01org/libyami/issues/new;
> +
> +LICENSE = "Apache-2.0"
> +SRC_URI = "https://github.com/01org/libyami/archive/libyami-${PV}.ta
> r.gz"
> +
> +LIC_FILES_CHKSUM =
> "file://COPYING.LIB;md5=3b83ef96387f14655fc854ddc3c6bd57"
> +
> +SRC_URI[md5sum] = "666909504c693f4b9186237b86ba43dc"
> +SRC_URI[sha256sum] =
> "1051d3e3366a933c4fbfb883b3900e81a8c0e4e1cd4d5a08b9c7d4e1bf7cec34"
> +
> +S = "${WORKDIR}/libyami-libyami-${PV}"
> +
> +PACKAGECONFIG ??= "${@bb.utils.contains("DISTRO_FEATURES", "x11",
> "x11", "", d)}"
> +PACKAGECONFIG[x11] = "--enable-x11,--disable-x11,virtual/libx11
> libxrandr libxrender"
> +
> +DEPENDS = "libva"
> +inherit autotools pkgconfig
> -- 
> 2.7.4
> 
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] gstreamer-vaapi and libva: check for opengl feature.

[Wold, Saul]

On Wed, 2016-11-30 at 16:26 +0200, Ismo Puustinen wrote:
> In case "opengl" is missing from DISTRO_FEATURES, libva fails to
> satisfy
> its dependencies. The dependency check is done by BitBake when
> meta-world-pkgdata gathers information about all available packages
> during image builds, even if libva isn't included in the build. This
> patch makes libva recipe be skipped if the "opengl" DISTRO_FEATURE
> isn't
> found.
> 
> Since missing libva breaks gstreamer-vaapi-1.0 build, the same check
> is
> done in gstreamer-vaapi-1.0 recipe too.
> 
Ismo,

While these patches are the same, I would prefer if we had 2 distinct
patches for libva and gstreamer-vaapi.

Is this related to what Mikko found recently with gstreamer-plugins-
bad?  I believe there was a missing dependency there also.

Sau!

> Signed-off-by: Ismo Puustinen 
> ---
>  common/recipes-multimedia/gstreamer/gstreamer-vaapi.inc | 4 +++-
>  common/recipes-multimedia/libva/libva_1.7.2.bb  | 4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/common/recipes-multimedia/gstreamer/gstreamer-vaapi.inc
> b/common/recipes-multimedia/gstreamer/gstreamer-vaapi.inc
> index 6dea9cf..59b0324 100644
> --- a/common/recipes-multimedia/gstreamer/gstreamer-vaapi.inc
> +++ b/common/recipes-multimedia/gstreamer/gstreamer-vaapi.inc
> @@ -16,7 +16,9 @@ SRC_URI = "https://gstreamer.freedesktop.org/src/${
> REALPN}/${REALPN}-${PV}.tar.x
>  
>  S = "${WORKDIR}/${REALPN}-${PV}"
>  
> -inherit autotools pkgconfig gtk-doc
> +inherit autotools pkgconfig gtk-doc distro_features_check
> +
> +REQUIRED_DISTRO_FEATURES ?= "opengl"
>  
>  PACKAGES =+ "${PN}-tests"
>  
> diff --git a/common/recipes-multimedia/libva/libva_1.7.2.bb
> b/common/recipes-multimedia/libva/libva_1.7.2.bb
> index d72074d..860ab77 100644
> --- a/common/recipes-multimedia/libva/libva_1.7.2.bb
> +++ b/common/recipes-multimedia/libva/libva_1.7.2.bb
> @@ -24,7 +24,9 @@ SRC_URI[sha256sum] =
> "5dd61cf16a5648b680e6146a58064e93be11bf4e65a9e4e30f1e9cb8ec
>  
>  DEPENDS = "libdrm virtual/mesa virtual/libgles1 virtual/libgles2
> virtual/egl"
>  
> -inherit autotools pkgconfig
> +inherit autotools pkgconfig distro_features_check
> +
> +REQUIRED_DISTRO_FEATURES ?= "opengl"
>  
>  EXTRA_OECONF = "--disable-dummy-driver"
>  
> -- 
> 2.9.3
> 
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 0/5] removed meta-isg and meta-mohonpeak

[Wold, Saul]

On Thu, 2016-11-24 at 01:33 +, Gupta, Rahul KumarXX wrote:
> Hi Saul,
> 
> > 
> > Unfortunately, this is too late for the meta-intel-6.0 release, we
> > built the rc2
> > yesterday. I will work on merging this early next week to master,
> > but it won't
> > be part of the morty release.
> > 
> > Sau!
> 
> Are these changes for master being reviewed?
> Please merge these to master if looks ok.
> 
Sorry, I was holding patches until we had the meta-intel-6.0 release
completed.  It completed last week and with the holiday, will be
released today.  

I merged your patches today into master.

Sorry and thanks for your patience.

Sau!

> Thanks
> Rahul
>  
> > 
> > 
> > On Fri, 2016-11-11 at 17:38 +0800, Rahul Kumar Gupta wrote:
> > > 
> > > Dear Maintainer(s),
> > > 
> > > This series of patches will
> > > Add ttyS1 to SERIAL_CONSOLES, since some of the intel boards are
> > > using
> > > this port. This variable will provide the login prompt to the
> > > console.
> > > 
> > > Add ASPEED graphics card driver to common BSP since some of the
> > > intel
> > > boards are using this.
> > > 
> > > Add support for mohonpeak in rmc. so that kernel boot/install
> > > procedure can be customized according to the board specific
> > > requirments.
> > > 
> > > Remove mohonpeak BSP layer ie. meta-mohonpeak from meta-isg
> > > layer.
> > > Since the plan is to consolidate all Intel SoC BSP into intel
> > > common
> > > BSP.
> > > 
> > > Remove empty layer meta-isg. since all content of this layer has
> > > been
> > > moved/consolidated to common.
> > > 
> > > The image has been tested with mohonPeak platform using intel-
> > > corei7-
> > > 64 BSP.
> > > 
> > > Please merge in master if it looks ok.
> > > 
> > > Thanks,
> > > 
> > > Rahul Kumar Gupta (5):
> > >   intel-core*: add ttyS1 to SERIAL_CONSOLES
> > >   intel-core*: Add ASPEED Xserver driver
> > >   rmc: Add support for MohonPeak platform
> > >   meta-isg/meta-mohonpeak: remove BSP layer
> > >   meta-isg: removing meta-isg layer
> > > 
> > >  .../rmc/boards/mohonpeak/BOOTENTRY.CONFIG  |   2 +
> > >  .../rmc/boards/mohonpeak/INSTALLER.CONFIG  |   3 +
> > >  common/recipes-bsp/rmc/boards/mohonpeak/KBOOTPARAM |   1 +
> > >  .../rmc/boards/mohonpeak/POSTINSTALL.sh|   3 +
> > >  common/recipes-bsp/rmc/boards/mohonpeak/boot.conf  |   4 +
> > >  .../recipes-bsp/rmc/boards/mohonpeak/install.conf  |   4 +
> > >  .../recipes-bsp/rmc/boards/mohonpeak/mohonpeak.fp  | Bin 0 ->
> > > 121
> > > bytes
> > >  conf/machine/intel-core2-32.conf   |   3 +-
> > >  conf/machine/intel-corei7-64.conf  |   3 +-
> > >  meta-isg/MAINTAINERS   |  44 --
> > >  meta-isg/README|   7 -
> > >  meta-isg/conf/layer.conf   |  12 --
> > >  meta-isg/meta-mohonpeak/COPYING.MIT|  17 ---
> > >  meta-isg/meta-mohonpeak/README | 164 -
> > > 
> > > 
> > >  meta-isg/meta-mohonpeak/README.sources |  18 ---
> > >  meta-isg/meta-mohonpeak/conf/layer.conf|  12 --
> > >  .../meta-mohonpeak/conf/machine/mohonpeak32.conf   |  22 ---
> > >  .../meta-mohonpeak/conf/machine/mohonpeak64.conf   |  22 ---
> > >  .../formfactor/formfactor/mohonpeak32/machconfig   |   3 -
> > >  .../formfactor/formfactor/mohonpeak64/machconfig   |   3 -
> > >  .../recipes-bsp/formfactor/formfactor_0.0.bbappend |   1 -
> > >  21 files changed, 21 insertions(+), 327 deletions(-)
> > >  create mode 100644 common/recipes-
> > > bsp/rmc/boards/mohonpeak/BOOTENTRY.CONFIG
> > >  create mode 100644 common/recipes-
> > > bsp/rmc/boards/mohonpeak/INSTALLER.CONFIG
> > >  create mode 100644 common/recipes-
> > > bsp/rmc/boards/mohonpeak/KBOOTPARAM
> > >  create mode 100644 common/recipes-
> > > bsp/rmc/boards/mohonpeak/POSTINSTALL.sh
> > >  create mode 100644 common/recipes-
> > bsp/rmc/boards/mohonpeak/boot.conf
> > > 
> > >  create mode 100644 common/recipes-
> > > bsp/rmc/boards/mohonpeak/install.conf
> > >  create mode 100644 common/recipes-
> > > bsp/rmc/boards/mohonpeak/mohonpeak.fp
> > >  delete mode 100644 meta-isg/MAINTAINERS
> > >  delete mode 100644 meta-isg/README
> > >  delete mode 100644 meta-isg/conf/layer.conf
> > >  delete mode 100644 meta-isg/meta-mohonpeak/COPYING.MIT
> > >  delete mode 100644 meta-isg/meta-mohonpeak/README
> > >  delete mode 100644 meta-isg/meta-mohonpeak/README.sources
> > >  delete mode 100644 meta-isg/meta-mohonpeak/conf/layer.conf
> > >  delete mode 100644 meta-isg/meta-
> > > mohonpeak/conf/machine/mohonpeak32.conf
> > >  delete mode 100644 meta-isg/meta-
> > > mohonpeak/conf/machine/mohonpeak64.conf
> > >  delete mode 100644 meta-isg/meta-mohonpeak/recipes-
> > > bsp/formfactor/formfactor/mohonpeak32/machconfig
> > >  delete mode 100644 meta-isg/meta-mohonpeak/recipes-
> > > bsp/formfactor/formfactor/mohonpeak64/machconfig
> > >  delete mode 100644 meta-isg/meta-mohonpeak/recipes-

Re: [meta-intel] BSP layer for AIMB-275

[Wold, Saul]

On Tue, 2016-11-22 at 13:59 -0500, Paul Knopf wrote:
> Is the meta-intel layer the one I should be using for this
> motherboard?
> 
> http://www.advantech.com/products/68ccaea2-9ff5-4f85-97f2-3d11244b0a0
> 8/aimb-275/mod_340f9d4a-17ed-44ac-9f00-5e96729ed7a7
> 
> I am using an i7 6700 with a Q170 chipset.
> 
You should be able to use the meta-intel layer with MACHINE=intel-
corei7-64.

Sau!

> Thanks,
> Paul Knopf
> Software Engineer
> Med X Change, Inc
> pkn...@medxchange.com
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 0/5] removed meta-isg and meta-mohonpeak

[Wold, Saul]

Hi Rhaul, Raymond:

Unfortunately, this is too late for the meta-intel-6.0 release, we
built the rc2 yesterday. I will work on merging this early next week to
master, but it won't be part of the morty release.

Sau!


On Fri, 2016-11-11 at 17:38 +0800, Rahul Kumar Gupta wrote:
> Dear Maintainer(s),
> 
> This series of patches will
> Add ttyS1 to SERIAL_CONSOLES, since some of the intel boards
> are using this port. This variable will provide the login prompt to
> the
> console.
> 
> Add ASPEED graphics card driver to common BSP since some of the intel
> boards are using this.
> 
> Add support for mohonpeak in rmc. so that kernel boot/install
> procedure can be customized according to the board specific
> requirments.
> 
> Remove mohonpeak BSP layer ie. meta-mohonpeak from meta-isg layer.
> Since the plan is to consolidate all Intel SoC BSP into intel common
> BSP.
> 
> Remove empty layer meta-isg. since all content of this layer has been
> moved/consolidated to common.
> 
> The image has been tested with mohonPeak platform using intel-corei7-
> 64 BSP.
> 
> Please merge in master if it looks ok.
> 
> Thanks,
> 
> Rahul Kumar Gupta (5):
>   intel-core*: add ttyS1 to SERIAL_CONSOLES
>   intel-core*: Add ASPEED Xserver driver
>   rmc: Add support for MohonPeak platform
>   meta-isg/meta-mohonpeak: remove BSP layer
>   meta-isg: removing meta-isg layer
> 
>  .../rmc/boards/mohonpeak/BOOTENTRY.CONFIG  |   2 +
>  .../rmc/boards/mohonpeak/INSTALLER.CONFIG  |   3 +
>  common/recipes-bsp/rmc/boards/mohonpeak/KBOOTPARAM |   1 +
>  .../rmc/boards/mohonpeak/POSTINSTALL.sh|   3 +
>  common/recipes-bsp/rmc/boards/mohonpeak/boot.conf  |   4 +
>  .../recipes-bsp/rmc/boards/mohonpeak/install.conf  |   4 +
>  .../recipes-bsp/rmc/boards/mohonpeak/mohonpeak.fp  | Bin 0 -> 121
> bytes
>  conf/machine/intel-core2-32.conf   |   3 +-
>  conf/machine/intel-corei7-64.conf  |   3 +-
>  meta-isg/MAINTAINERS   |  44 --
>  meta-isg/README|   7 -
>  meta-isg/conf/layer.conf   |  12 --
>  meta-isg/meta-mohonpeak/COPYING.MIT|  17 ---
>  meta-isg/meta-mohonpeak/README | 164 -
> 
>  meta-isg/meta-mohonpeak/README.sources |  18 ---
>  meta-isg/meta-mohonpeak/conf/layer.conf|  12 --
>  .../meta-mohonpeak/conf/machine/mohonpeak32.conf   |  22 ---
>  .../meta-mohonpeak/conf/machine/mohonpeak64.conf   |  22 ---
>  .../formfactor/formfactor/mohonpeak32/machconfig   |   3 -
>  .../formfactor/formfactor/mohonpeak64/machconfig   |   3 -
>  .../recipes-bsp/formfactor/formfactor_0.0.bbappend |   1 -
>  21 files changed, 21 insertions(+), 327 deletions(-)
>  create mode 100644 common/recipes-
> bsp/rmc/boards/mohonpeak/BOOTENTRY.CONFIG
>  create mode 100644 common/recipes-
> bsp/rmc/boards/mohonpeak/INSTALLER.CONFIG
>  create mode 100644 common/recipes-
> bsp/rmc/boards/mohonpeak/KBOOTPARAM
>  create mode 100644 common/recipes-
> bsp/rmc/boards/mohonpeak/POSTINSTALL.sh
>  create mode 100644 common/recipes-bsp/rmc/boards/mohonpeak/boot.conf
>  create mode 100644 common/recipes-
> bsp/rmc/boards/mohonpeak/install.conf
>  create mode 100644 common/recipes-
> bsp/rmc/boards/mohonpeak/mohonpeak.fp
>  delete mode 100644 meta-isg/MAINTAINERS
>  delete mode 100644 meta-isg/README
>  delete mode 100644 meta-isg/conf/layer.conf
>  delete mode 100644 meta-isg/meta-mohonpeak/COPYING.MIT
>  delete mode 100644 meta-isg/meta-mohonpeak/README
>  delete mode 100644 meta-isg/meta-mohonpeak/README.sources
>  delete mode 100644 meta-isg/meta-mohonpeak/conf/layer.conf
>  delete mode 100644 meta-isg/meta-
> mohonpeak/conf/machine/mohonpeak32.conf
>  delete mode 100644 meta-isg/meta-
> mohonpeak/conf/machine/mohonpeak64.conf
>  delete mode 100644 meta-isg/meta-mohonpeak/recipes-
> bsp/formfactor/formfactor/mohonpeak32/machconfig
>  delete mode 100644 meta-isg/meta-mohonpeak/recipes-
> bsp/formfactor/formfactor/mohonpeak64/machconfig
>  delete mode 100644 meta-isg/meta-mohonpeak/recipes-
> bsp/formfactor/formfactor_0.0.bbappend
> 
> -- 
> 1.9.1
> 
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel