Re: [meta-intel] [meta-intel PATCH] xf86-video-mga: upgrade and fix build

[Burton, Ross]

On 29 November 2012 23:37, Tom Zanussi tom.zanu...@intel.com wrote:
 OK, no problem, looks like the below should fix it.  I'll test it and
 pull both in once I've verified...

 XAA has been dropped, so we need to drop the xaa module.

The driver AFAICS is using the EXA module now, so you'll want to add a
dependency on that.

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

Re: [meta-intel] [PATCH 1/1] Revert emgd-driver-bin: add xorg-abi-video- dependency

[Burton, Ross]

On 2 December 2012 23:19,  tom.zanu...@intel.com wrote:
 There's no explanation of what the actual problem was that this commit
 fixes - likely it was in response to the packaging problems causing
 YOCTO #3501 and YOCTO #3502.  In any case, nothing should cause a
 regression like this since xserver-xorg is pinned at 1.9.3 and its
 contents shouldn't change to cause something like 'xorg-abi-video' to
 disappear.

There was a thread on oe-core and the relevant oe-core commits had
plenty of explanation:

commit bc41dfb9cd2d3b90d97fa051c90d2f53bacde059
Author: Ross Burton ross.bur...@intel.com
Date:   Mon Oct 22 10:37:24 2012 +0100

xserver-xorg: add runtime provides for the driver ABI version

The xserver driver ABIs can and do change in a way that is unrelated to the
version of xserver, so it's entirely possible to build an image that has a
mismatch between the server ABI version and the version that the
drivers were
built against.  xserver detects this and refuses to load the modules.

By adding RPROVIDEs to the xserver package that describe the ABI
versions it has
(such as xorg-abi-video-13, xorg-abi-input-11), drivers can RDEPEND on the
version that they were built against.  This means that when the ABIs change,
there will be package dependency errors at image time instead of images that
build fine but don't work.

(From OE-Core rev: 8ef5f205aec04140198d5ba0f5c405ae6e977dbe)

You may have pinned xserver-xorg in the bitbake to 1.9.3 but:

1) it's entirely possible for the package feed to get 1.13 from
another MACHINE, because they'll both be in the core2 arch feed
2) it's enforcing the ABI relationship which can't be expressed in any other way

 Also there doesn't appear to any xorg-abi-video-8, so it's doubtful
 that this commit actually fixed the problem it was trying to fix -
 should it instead be xorg-video-abi-8 which does exist?

Really?

ross@melchett 
/data/poky-master/tmp/work/core2-poky-linux/xserver-xorg/1_1.9.3-r2/deploy-ipks/core2
$ dpkg -I xserver-xorg_1.9.3-r2_core2.ipk
...
 Provides: xorg-abi-video-8, xorg-abi-input-11

Where are you seeing xorg-video-abi-8?  I'm concerned that the RPM
backend is messing things up.

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

Re: [meta-intel] BSP for Intel Atom N270 based system

[Burton, Ross]

On 27 February 2013 14:10, Peter Bergin peter.ber...@qmatic.com wrote:
 I will start a project based on Yocto project 1.3 and the target system is a
 board with a Intel Atom N270 processor together with Intel 945GSE  ICH7M
 system chipset. Looking into meta-intel I can not find any MACHINE that fits
 my configuration. I am quite new to Yocto development and would like advice
 on where to start and how I can create a suitable BSP for my board. Any
 ideas?

I don't think there's anything in meta-intel that's an exact match,
but the atom-pc BSP in meta-yocto-bsp should be a good start as it's
not very specific.

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

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

[Burton, Ross]

On 7 March 2013 12:57, Laurentiu Palcu laurentiu.pa...@intel.com wrote:
 Hmmm, it seems that libva-egl package is not built because, in the new
 version, the check for egl availability is done using pkg-config. And
 the emgd-driver-bin does not provide an egl.pc file...

 There are 4 solutions to this:
  * make libva use the old method of detecting egl, so it builds libva-egl 
 anyway;
  * override pkg-config by providing EGL_CFLAGS and EGL_LIBS separately to 
 configure.
I tested it and it worked fine adding the following snippet to libva 
 recipe:

 do_configure_prepend () {
 export EGL_CFLAGS=-I${STAGING_INCDIR}
 export EGL_LIBS=-L${STAGING_LIBDIR} -lEGL
 }

  * we talk with the egmd maintainers to include *.pc file in the package;
  * we create the *.pc files ourselves;

 What do you guys think?

More than this will be looking for egl.pc, so create it ourselves in
the short term and talk to the EMGD guys so they add it for the long
term.

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

Re: [meta-intel] [PATCH] emgd-driver-bin: add pkgconfig files

[Burton, Ross]

On 18 March 2013 22:53, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
 I am also seeing build errors:

 | eglut.c: In function '_eglutDestroyWindow':eglut.c: In function 
 '_eglutDestroyWindow':
 |
 | eglut.c:55:32: error: 'EGL_SCREEN_BIT_MESA' undeclared (first use in this 
 function)eglut.c:55:32: error: 'EGL_SCREEN_BIT_MESA' undeclared (first use in 
 this function)

mesa-demos assumes that it's building against mesa, so it won't work
against EMGD.

There's a bug for this in our bugzilla somewhere - we need to make it
either hard-depend on mesa-dri or patch it to check for mesa symbols
before using them.

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

Re: [meta-intel] emgd-driver-dev and libgl-mesa-dev packaging conflict

[Burton, Ross]

On 19 April 2013 08:59, Laurentiu Palcu laurentiu.pa...@intel.com wrote:
 Is libva the only known package that needs the .pc files?

 Laurentiu, care to comment as this was your patch we're considering
 reverting?

 Yes, libva is the package needing the gl.pc file (libva-egl to be more
 specific). We could revert the commit specified and add the following
 lines in the libva_1.1.1.bb:

 do_configure_prepend () {
 export EGL_CFLAGS=-I${STAGING_INCDIR}
 export EGL_LIBS=-L${STAGING_LIBDIR} -lEGL
 }

 This will still allow building libva-egl and avoid using pkgconfig.

If I remember correctly, EMGD only provides GLES/EGL and it relies on
Mesa for libGL, right?  So EMGD doesn't need its own gl.pc because it
doesn't provide libGL.  So removing gl.pc from EMGD is the correct
fix.

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

Re: [meta-intel] emgd-driver-dev and libgl-mesa-dev packaging conflict

[Burton, Ross]

On 19 April 2013 22:33, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
 This is issue with EMGD bsps only. So we will need to test only sdk images for
 EMGD BSPs with ipk packaging. Rest of the BSPs would not get affected if we
 just revert the .pc commit for the emgd recipe.

Please don't revert the entire commit, just drop the .pc files that
are invalid because EMGD *doesn't* provide those libraries.  As far as
I can tell, this is gl.pc.  If you revert the commit then we'll have
to revert the revert later, and then we're back here again.

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

Re: [meta-intel] emgd-driver-dev and libgl-mesa-dev packaging conflict

[Burton, Ross]

On 21 April 2013 17:52, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
 Hi Ross,
   As per Laurentiu's email as seen bellow he is proposing a different fix to 
 the issue, so let's revert the commit and fix the issue properly when it will 
 be needed.

And as per Laurentiu's other email, he agrees with me:

Now that I better think of it, egl.pc is the one libva needs... So
Ross is correct. Removing gl.pc should be the right fix.

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

Re: [meta-intel] [PATCH 0/2] Package upgrades

[Burton, Ross]

On 10 July 2013 16:23, Laurentiu Palcu laurentiu.pa...@intel.com wrote:
 The packages were compiled for sugarbay and also a core-image-sato image has
 been built. No issues encountered. Not tested on real HW though. Any help
 would be appreciated.

My normal test for this is to do a gst-launch on a 720p .mp4 file and
verify the pipeline and that it's playing at full speed.  I presume
there's some NUCs in the office, can you do a build for that?

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

Re: [meta-intel] [PATCH 0/4] misc meta-intel Fixes

[Burton, Ross]

On 14 August 2013 20:46,  nitin.a.kam...@intel.com wrote:
 Recently an issue was observed and fixed on meta-minnow, which was breaking
 builds when DISTRO is not poky. The same issue also exist on the
 crownbay, emenlow, fri2  sys940x BSPs.
   Here are the commits to fix the issue for these BSPs.

Not sure I like changing DISTRO_FEATURES from within a BSP, that's a
layering violation in my opinion.

There was a patch a week or so ago to add a
distro_features_check.bbclass, which let you do this in recipes:

  inherit distro_features_check
  REQUIRED_DISTRO_FEATURES = x11

There was some debate on the patch but it's fairly trivial to do this
sort of check in an anonymous Python function without the class,
systemd does this to ensure it only gets built in a distribution with
the systemd feature.

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

Re: [meta-intel] [PATCH 0/4] misc meta-intel Fixes

[Burton, Ross]

On 14 August 2013 21:49, Darren Hart darren.h...@intel.com wrote:
 So the correct way to build from oe-core without meta-yocto would be to
 append these values to DISTRO_FEATURES in local.conf? That or define our
 own DISTRO... which is basically what including meta-yocto does with
 poky. I did pull this in for Minnow and will now have to revert.

Yeah, you can use DISTRO_FEATURES_append =  opengl in your
local.conf if you want to do a pure bitbake+oe-core build.

 If I understood correctly, the REQUIRED_DISTRO_FEATURES mechanisms was
 only proposed and does not exist currently?

Correct.

 What is the current mechanism for this? Do we have one of the tasks in
 the emgd driver recipe check for the required features in distro config
 and error out if they are missing?

The systemd recipe has a fairly idiomatic way of skipping packages
depending on the distro features, which will result in an message
saying the package is being skipped, and then a build failure when the
dependencies don't resolve.

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

Re: [meta-intel] [PATCH 1/1] emgd-driver-bin: mark opengl as a required distro feature

[Burton, Ross]

On 27 August 2013 18:57,  nitin.a.kam...@intel.com wrote:
 +inherit distro_features_check
 +REQUIRED_DISTRO_FEATURES = opengl
 +

Looks good.

Acked-By: Ross Burton ross.bur...@intel.com

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

Re: [meta-intel] [PATCH 4/5] xf86-video-intel: mark opengl as a required distro feature

[Burton, Ross]

On 5 September 2013 04:38,  nitin.a.kam...@intel.com wrote:
 From: Nitin A Kamble nitin.a.kam...@intel.com

 This recipe needs 'opengl' distro feature enabled. Otherwise build
 fails with this error:

 | intel.h:66:18: fatal error: dri2.h: No such file or directory

Several things.

1) why does meta-intel have it's own copy of the driver when there's
already one in oe-core?
2) configure has a --disable-dri option, did you see if this works?
Glancing at the source there might actually be a hard dependency on
DRI headers, but that can be something we can fix in the X server.

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

Re: [meta-intel] [PATCH 4/5] xf86-video-intel: mark opengl as a required distro feature

[Burton, Ross]

On 5 September 2013 18:42, Darren Hart dvh...@linux.intel.com wrote:
  2) configure has a --disable-dri option, did you see if this works?
  Glancing at the source there might actually be a hard dependency on DRI
  headers, but that can be something we can fix in the X server.

 Why do you want to remove the DRI feature from the Intel X driver?

 By doing that conditionally, we can ensure it builds with or without
 opengl.

Just chatted with the maintainer and he claims that if --disable-dri
doesn't work we can file bugs/patches to make it work.

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

Re: [meta-intel] [OE-core] [Patch-v2 1/1] mesa: avoid unnecessary rerunning of tasks

[Burton, Ross]

On 5 September 2013 09:33, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
 I'd also appreciate someone (Ross maybe?) confirming that if we build
 application A against mesa, then change over to a machine that uses emgd
 and swizzle the libs around in the sysroot, do we need to recompile the
 app? This approach is assuming we do not need to do that. If we do,
 there is a different approach we need to take.

So what's happening is that we're revising the original OpenGL policy
that I posted in October last year:

http://lists.openembedded.org/pipermail/openembedded-core/2012-October/070122.html

tl;dr: I proposed that 1) we rename all GL packages so they identify
their provider (ie libgl-mesa, we do that), 2) no dependencies on
specific GL implementations, 3) only Mesa stages.  The theory was that
Mesa can be considered a canonical implementation of the various GL
platforms and that we can *build* against Mesa but *install* the right
hardware-specific GL implementation into the images.

Nice in theory and it should work, but sadly that isn't the case - the
thread has more details.  Short version is that some applications *do*
rely on specific GL headers, so you can't just swap them around in
reality.

Maybe it is time to have a mesa-gl recipe alongside mesa that *just*
builds the GL libraries.  EMGD can depend on it for the driver modules
it installs, and presumably other vendors with binary drivers can
install it for the software rendering/GLX support (Otavio etc, please
step in here!).

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

Re: [meta-intel] [PATCH 4/5] xf86-video-intel: mark opengl as a required distro feature

[Burton, Ross]

On 6 September 2013 17:00, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
 Even though it is technically possible, it will be crippling the Intel 
 graphics driver.
 Do we have to do it? Is the other, non-crippling option of requesting opengl 
 distro
 feature so bad?

Feel free to put a comment along the lines that some of the hardware
acceleration requires the opengl distro feature, but as the driver
does (should) build without DRI then we should respect the users
choice if they explicitly decided to not have opengl in
DISTRO_FEATURES.

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

Re: [meta-intel] [PATCH] xf86-video-mga: respect opengl DISTRO_FEATURE

[Burton, Ross]

On 12 September 2013 21:57, Darren Hart dvh...@linux.intel.com wrote:
 So... if DISTRO_FEATURES does contain opengl and dri, how do we ensure
 glproto, virtuial/libgl, etc. are built prior to this recipe? That's why
 they were in DEPENDS right?

No idea why they were in depends, as they're not used by the build.  I
should have mentioned they were removed on purpose.

Oh, note that this is untested as I don't have any MGA hardware.  Can
anyone test the change with and without the opengl feature? (easy, now
that it's a matter of DISTRO_FEATURES_remove=opengl).

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

Re: [meta-intel] [PATCH] xserver-xf86-config: remove redundant files, clean up broken ones

[Burton, Ross]

On 19 September 2013 00:31, Darren Hart dvh...@linux.intel.com wrote:
 On Wed, 2013-09-18 at 23:23 +0100, Ross Burton wrote:
 Most BSPs appear to be derived from what appears to be a stale copy of the
 atom-pc xorg.conf which was either repeating defaults (the screen
 configuration), pointlessly hard-coding (specifying video driver when X can
 auto-probe), or actively harmful (disabling hotplugged input devices).  
 Delete
 the files which can be removed, and remove the bad hotplug disabling options
 from the others.

 This has been something I've wanted to see improved for a long time.
 Typically we do changes like with one patch per BSP to help keep things
 a bit more flexible in the face of regressions.

I started doing that but then got rapidly bored with copy-paste...  I
can split it up though.

 Which of these BSPs did you test and verify work after this patch?

Two classes of patches: delete the file and trim the file.

Where xorg.conf was deleted the only hardware I can (and did) test it
on was NUC.  I guess a representative sample of vesa and mga hardware
should be verified to still boot.

One instance of the trim patch was tested by Saul on his Minnow (whose
report of a broken touchscreen prompted this series) and oe-core has
had the same change for atom-pc/genericx86 for some time now.

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

Re: [meta-intel] [PATCH] xserver-xf86-config: remove redundant files, clean up broken ones

[Burton, Ross]

On 19 September 2013 00:43, Burton, Ross ross.bur...@intel.com wrote:
 Typically we do changes like with one patch per BSP to help keep things
 a bit more flexible in the face of regressions.

 I started doing that but then got rapidly bored with copy-paste...  I
 can split it up though.

The same patch series but split per BSP is now at
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=ross/xorg.

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

Re: [meta-intel] [PATCH 1/4] crownbay, crownbay-noemgd: fix xorg.conf

[Burton, Ross]

On 1 October 2013 19:35,  nitin.a.kam...@intel.com wrote:
 +OptionDontZap  0

This is the default, so you won't need this.  I'd also love to see
some xorg logs to understand why turning off hotplug makes input work
- maybe the udev environment is broken.

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

Re: [meta-intel] [PATCH 0/1] mesa.bbappend: sync version with oecore

[Burton, Ross]

From what I can tell the bbappend isn't being used anymore (thanks to
mesa-gl) so we can just delete it.

Ross

On Monday, 4 November 2013, Laurentiu Palcu wrote:

 Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com javascript:;
 ---
  .../{mesa_9.1.6.bbappend = mesa_9.2.2.bbappend}   |0
  1 file changed, 0 insertions(+), 0 deletions(-)
  rename common/recipes-graphics/mesa/{mesa_9.1.6.bbappend =
 mesa_9.2.2.bbappend} (100%)

 diff --git a/common/recipes-graphics/mesa/mesa_9.1.6.bbappend
 b/common/recipes-graphics/mesa/mesa_9.2.2.bbappend
 similarity index 100%
 rename from common/recipes-graphics/mesa/mesa_9.1.6.bbappend
 rename to common/recipes-graphics/mesa/mesa_9.2.2.bbappend
 --
 1.7.9.5

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

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

Re: [meta-intel] [PATCH 0/4] mesa build warning fixes

[Burton, Ross]

On 14 November 2013 22:15,  tom.zanu...@intel.com wrote:
 From: Tom Zanussi tom.zanu...@intel.com

 While build-testing, I found a bunch of BSPs that didn't prefer
 the a matching mesa version, resulting in lots of warning spewage.

There's only one version of Mesa in oe-core *and* mesa isn't used by
these BSPs anymore (they use mesa-gl).  I recommend deleting these
lines.

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

Re: [meta-intel] [PATCH 2/2] xf86-video-ast: Enable ASPEED Tech Graphic Card

[Burton, Ross]

On 18 November 2013 07:57,  boon.leong@intel.com wrote:
 +DEPENDS += virtual/libx11 drm xf86driproto glproto virtual/libgl 
 libpciaccess

The configure script doesn't appear to check for GL or DRM but does
check for Xv which you've not listed.  Please start from an empty
DEPENDS and add dependencies from configure.ac.

 +EXTRA_OECONF += --enable-dri

configure.ac doesn't define this.

 +PR = r1

Should be r0 for an initial recipe, and it's not needed for new
recipes now we have the PR server.

 +COMPATIBLE_HOST = '(i.86.*-linux|x86_64.*-linux)'

Is this actually true or more copy/paste?

 +RDEPENDS_${PN} = xserver-xorg-module-exa

This driver doesn't use EXA, it has optional support for XAA.

This looks a lot like a driver recipe that was created by copy-pasting
an existing driver, without any validation.  Please don't do that.

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

Re: [meta-intel] [minnowboard] EMGD and Wayland/Weston on minnowboard

[Burton, Ross]

On 20 November 2013 16:13, Behrens, Holger holger.behr...@windriver.com wrote:
 Currently the EMDG relnotes states
 Note: MeeGo 1.2 with Wayland feature is mainly for evaluation and
   testing purposes; it is not for production usage.

 any plans to extend the Wayland/Weston (eval. and test) support to the
 Minnowboard in the future (core-image-weston.bb / DISTRO_FEATURES +=  
 wayland)?

This is a question for the EMGD driver team as it would be their
closed-source driver that needs to be modified.  I suspect the answer
is no, a more expanded version would be give us a business need.
I do know that as of last April they certainly had no official plan to
revive Wayland support in the driver.

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

Re: [meta-intel] [minnowboard] EMGD and Wayland/Weston on minnowboard

[Burton, Ross]

On 21 November 2013 08:00, Behrens, Holger holger.behr...@windriver.com wrote:
 Thank you for the update.
 Will have to go with an ARM based board instead then.

Or anything based on Bay Trail for Atom, or obviously anything
not-Atom.  Alternatively speak to the EMGD team if you can demonstrate
a business case for adding Wayland support: I'd love to see it added
and from memory there wasn't much API missing.

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

Re: [meta-intel] Enable Wayland in an image - Intel baytaril platform

[Burton, Ross]

On 29 November 2013 08:06, Somasekhar Reddy Mallireddigari -ERS, HCL
Tech somasekha...@hcl.com wrote:
 We are trying to enable the Weston in image. We are building the
 “baytrail32-noemgd” image.

 We followed https://wiki.yoctoproject.org/wiki/Wayland


 When we try to launch Weston. We are getting errors (screen shot attached).

No screenshot is attached, and it's more useful to redirect the errors
to a file so you can include them in the email as text instead of a
screenshot.

Note that by using -noemgd you'll have almost zero GPU acceleration,
and as far as I'm aware nobody has tested the gma500 driver with
Weston.

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

Re: [meta-intel] Enable Wayland in an image - Intel baytaril platform

[Burton, Ross]

On 2 December 2013 06:09, Somasekhar Reddy Mallireddigari -ERS, HCL
Tech somasekha...@hcl.com wrote:
 [06:37:12,675] Loading modules '/usr/lib/weston/x11-backend.so'

 [06:37:12,680] initializing x11 backend

 libEGL warning: DRI2: failed to authenticate

 libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/dri)

 libEGL warning: GLX: failed to load GLX

 [06:37:12,682] failed to initialize display

Note that it's using the X11 backend.  Are you trying to run Weston
inside X, or do you mean to run it outside of X?  I'm guessing that
your baytrail-noemgd distro is broken, as that should mean it uses
xf86-video-intel with full GL support.

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

Re: [meta-intel] [meta-fri] Graphics broken?

[Burton, Ross]

On 5 December 2013 11:31, Andrei Gherzan and...@gherzan.ro wrote:
 Testing xbmc on this, seems like hw accel is not working. Videos are very
 slow and I get this output:
 libva: Trying to open /usr/lib/dri/emgd_drv_video.so
 libva: va_openDriver() returns -1

Try using low-level tools such as vainfo, might give more useful information.

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

Re: [meta-intel] [meta-fri] Graphics broken?

[Burton, Ross]

On 5 December 2013 12:51, Andrei Gherzan and...@gherzan.ro wrote:
 Yes. I used that too. Nothing more than:
 libva: VA-API version 0.32.1
 libva: va_getDriverName() returns 0
 libva: Trying to open /usr/lib/dri/emgd_drv_video.so
 libva: va_openDriver() returns -1
 vaInitialize failed with error code -1 (unknown libva error),exit

Useful. :/   Unless you fancy testing selected reverts I'm out of
ideas, maybe Nitin on Darren have some thoughts.

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

Re: [meta-intel] Enable Wayland in an image - Intel baytaril platform

[Burton, Ross]

On 9 December 2013 10:56, Somasekhar Reddy Mallireddigari -ERS, HCL
Tech somasekha...@hcl.com wrote:
 [14:34:50,497] fatal: failed to create compositorte ioctl for device

I've never seen that error when starting Weston, but I've not used
that BSP (nor can I look at it) and I've not got that hardware.

I recommend approaching Wayland engineers to debug this.

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

Re: [meta-intel] [PATCH 1/7] xf86-video-ast: new recipe for ASPEED Technology Card

[Burton, Ross]

On 2 April 2014 12:45,  boon.leong@intel.com wrote:
 +DEPENDS += virtual/libx11 libpciaccess

Drivers shouldn't be linking to client libraries so you should be able
to drop libx11 from here.

 +PR = r0

No need for this, remove.

 +COMPATIBLE_HOST = '(i.86.*-linux|x86_64.*-linux)'

Does this driver really only work on x86 hardware?

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

Re: [meta-intel] [PATCH 1/7] xf86-video-ast: new recipe for ASPEED Technology Card

[Burton, Ross]

On 2 April 2014 16:30, Ong, Boon Leong boon.leong@intel.com wrote:
 Does this driver really only work on x86 hardware?
 I only validate it on x86 hardware. Since this goes under meta-intel, I 
 suppose that is fine?
 Or, should I just remove that line entirely? I was referencing recipe written 
 for mga.

Unless the recipe is *strictly* for a specific machine then these
lines are meaningless, please remove it.

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

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

[Burton, Ross]

As per Nitin's comments, I've just re-pushed this branch
(ross/canterbury) with extra inline comments.

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

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

[Burton, Ross]

Hi,

I've been having a quick look at the image generation code and am
wondering if appending supplementary cpio blobs to an initramfs is
something that is actually common and we should add support for that
directly to the initramfs generation.

Alternatively, using IMAGE_POSTPROCESS_COMMAND in
core-image-minimal-initramfs.bbappend should let you trivially append
a cpio (generated directly using cpio, not image.bbclass) to the
generated image.

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

Re: [meta-intel] Supporting multiple GL providers

[Burton, Ross]

On 5 July 2014 00:51, Ash Charles ashchar...@gmail.com wrote:
 This seems like generally useful feature any time there are
 multiple GL providers for the same arch---is this assessment
 reasonable?

Yes, it is.

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

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

[Burton, Ross]

On 8 July 2014 08:00,  wei.sern.c...@intel.com wrote:
 +# Recipe Ingredients (source, patch, etc)
 +# Package Run-time dependency

No need to add comments explaining what variables are for.

 +S = ${WORKDIR}/dpdk-${PV}

This is the default, remove it.

 +export INSTALL_PATH = /opt/dpdk

Why does DPDK get installed into /opt, and why can't it be fully
installed into ${prefix}?

 +do_compile () {
 +   unset LDFLAGS TARGET_LDFLAGS BUILD_LDFLAGS
 +
 +   cd ${S}/${RTE_TARGET}
 +   oe_runmake EXTRA_LDFLAGS= --sysroot=${PKG_CONFIG_SYSROOT_DIR} \
 +  EXTRA_CFLAGS= --sysroot=${PKG_CONFIG_SYSROOT_DIR} \

You don't want to use PKG_CONFIG_SYSROOT_DIR, as that's for use by
pkg-config.  Use $STAGING_DIR_HOST.

 +do_compile_append () {

Merge do_compile and do_compile_append.

 +   case `basename ${app}` in
 +   dpdk_qat) continue
 +;;
 +   vhost) continue
 +   ;;
 +   vhost_xen) continue
 +   ;;
 +   esac

That's a lot of code for a simple test.  Using | will let you do
multiple tests in a single case, or just use test.

 +   #
 +   ### Creating necessary folder under image directory
 +   ### Those folders are to host compiled binary, scripts,
 +   ### libraries.
 +   #

No need to explain something obvious, every do_install has to make the
directories it installs into.

 +do_install_append () {

Merge do_install and do_install_append.

 +   #Install test applications
 +   #Install example applications

More comments for obvious code.

 +# Split the DPDK ingredient into several packages defined by PACKAGES.
 +# Please refer to ${WORKDIR}/packages-split/
 +# Note: DPDK ingredient only goes into one of the split package
 +# Note: For kernel module built from DPDK, please don't include
 +# them in the following package as they go into kernel-module-* split
 +# package

Remove obvious comments.

 +FILES_${PN}-dbg +=  \
 +   ${INSTALL_PATH}/.debug \
 +   ${INSTALL_PATH}/doc \
 +   ${INSTALL_PATH}/${RTE_TARGET}/app/.debug \
 +   

Copy-paste error, putting documentation into the -dbg package?

 +FILES_${PN}-dev +=  \
 +   ${INSTALL_PATH}/${RTE_TARGET}/.config \
 +   ${includedir} \
 +   ${includedir}/arch \
 +   ${includedir}/exec-env \
 +   
 +
 +FILES_${PN} +=   ${INSTALL_PATH}/${RTE_TARGET}/app/ \
 +/lib64/ \
 +${INSTALL_PATH}/tools \
 +   

Hard-coded /lib64?

 +FILES_${PN}-staticdev += ${libdir}/*.a

This is the default, remove.

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

Re: [meta-intel] [PATCH 3/3] meta-romley: add Intel DPDK v1.6.0r2 support Romley machine config

[Burton, Ross]

On 8 July 2014 08:00,  wei.sern.c...@intel.com wrote:
 +PREFERRED_PROVIDER_virtual/extended ?= dpdk

What does this do?

 +PREFERRED_VERSION_dpdk ?= 1.6.0r2%

There's only one version, so you don't need a preferred version.

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

Re: [meta-intel] [PATCHv2 2/2] meta-romley: add Intel DPDK v1.6.0r2 support Romley machine config

[Burton, Ross]

On 10 July 2014 09:40,  wei.sern.c...@intel.com wrote:
 Added MACHINE_EXTRA_RRECOMMENDS to include dpdk for romley machine
 configuration so that building on Romley will automatically pick up
 Intel DPDK.

As far as I'm aware DPDK on it's own doesn't serve any purpose - it's
a development kit/library and you need to build *something* against it
to get the increased network performance for that application.

If this is the case then it shouldn't be installed by default in every
romley image.

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

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

[Burton, Ross]

On 10 July 2014 09:40,  wei.sern.c...@intel.com wrote:
 +++ 
 b/common/recipes-extended/dpdk/dpdk/dpdk-1.6.0r2-app-test-fix-build-switches-to-enable-cmdline-tests.patch
 @@ -0,0 +1,49 @@
 +From cf953d2bfa7df9aa67459b333db4d4d8a9e72fd6 Mon Sep 17 00:00:00 2001
 +From: Thomas Monjalon thomas.monja...@6wind.com
 +Date: Fri, 27 Jun 2014 11:21:11 +0200
 +Subject: [PATCH] app/test: fix build switches to enable cmdline tests
 +
 +There were 2 typos since these commits (in 1.6.0 releases):
 +   21a7f4e264 fix build without librte_cmdline
 +   cac6d08c8b replace --use-device option by --pci-whitelist and --vdev
 +In makefiles, the build options are prefixed with CONFIG_RTE_
 +but in .c file, it is only RTE_.
 +
 +These typos were disabling cmdline unit tests and test of --vdev eth_ring 
 option.
 +
 +Signed-off-by: Thomas Monjalon thomas.monja...@6wind.com
 +Acked-by: Pablo de Lara pablo.de.lara.gua...@intel.com

Patches need to have a Signed-Off-By (presumably, you) and
Upstream-Status (in this case, Backport) at the top.  This is so we
know who is responsible for bringing the patch into oe-core, and that
as a backport its likely to be removed in the future.

 +# Recipe Ingredients (source, patch, etc)

Pointless comment.

 +export INSTALL_PATH = ${prefix}/dpdk

Urgh, if it can't be told to install into $datadir $libdir etc, then that's sad.

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

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

[Burton, Ross]

On 10 July 2014 09:40,  wei.sern.c...@intel.com wrote:
 This is an initial version of Intel Data Plane Development Kits
 (DPDK) recipe support. This recipe is targetting on Intel DPDK
 v1.6.0r2. This recipe is created under meta-intel/common because
 Intel DPDK can be commonly used several Intel BSP platforms such
 as Romley, Crystal-Forest  Mohon-peak. We resolved examples apps
 build failure found in v1.6.0-r2 by cherry-picking patches from
 v1.7.0 as they are not planned to be fixed in v1.6.0-r2. The
 example app build failure are found in qos_sched, eal_flags_autotest
 and cmdline_autotest.

This fails a build from clean:

| 
/data/poky-master/tmp/work/nuc-poky-linux/dpdk/1.6.0r2-r0/temp/run.do_compile.7306:
129: [: cmdline: unexpected operator
| 
/data/poky-master/tmp/work/nuc-poky-linux/dpdk/1.6.0r2-r0/temp/run.do_compile.7306:
129: [: dpdk_qat: unexpected operator

Your logic is probably expanding to empty strings.

| make[1]: Entering directory
`/data/poky-master/tmp/work/nuc-poky-linux/dpdk/1.6.0r2-r0/dpdk-1.6.0r2/examples/dpdk_qat/build'
|   CC main.o
|   CC crypto.o
| 
/data/poky-master/tmp/work/nuc-poky-linux/dpdk/1.6.0r2-r0/dpdk-1.6.0r2/examples/dpdk_qat/crypto.c:64:17:
fatal error: cpa.h: No such file or directory
|  #include cpa.h

Missing build dependency?  Before submitting, it's best to always wipe
your build directory (just delete tmp/, or use wipe-sysroot) to verify
that you have the correct build dependencies.

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

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

[Burton, Ross]

On 19 July 2014 01:18,  nitin.a.kam...@intel.com wrote:
 +IMAGE_TYPES += cpio.gz.ucode
 +COMPRESSIONTYPES += gz.ucode
 +COMPRESS_CMD_gz.ucode = ${COMPRESS_CMD_gz}; cat ${EARLY_UCODE_CPIO} 
 ${IMAGE_NAME}.rootfs.${type}.gz  ${IMAGE_NAME}.rootfs.${type}.gz.ucode
 +COMPRESS_DEPENDS_gz.ucode = ${COMPRESS_DEPENDS_gz} intel-microcode

Something about this has always bugged me and I just realised what it
is.  As I understand it the kernel allows an arbitrary number of cpio
archives to be appended to the kernel, but our image creation code
expects one.  This class is basically working around that limitation
by being a specialised image type that appends another hard-coded
file.

If the image creation code was changed to expect a list, then we
wouldn't need this class at all but could simply do INITRD +=
$(EARLY_UCODE_CPIO).

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

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

[Burton, Ross]

On 25 July 2014 17:49, Kamble, Nitin A nitin.a.kam...@intel.com wrote:
 Maybe we can wait for the intel microcode to go intoe linux-firmware, then 
 this recipe will not be needed at all. But for that to happen intel-microcode 
 needs to show up in the linux-firmware repo, and I will push on that instead 
 of pushing this recipe.

This seems like the path of least pain for us certainly.

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

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

[Burton, Ross]

On 29 August 2014 18:22,  nitin.a.kam...@intel.com wrote:
  # if enabled, include user space intel microcode loading support in the 
 generated images.
  MACHINE_EXTRA_RRECOMMENDS = intel-microcode iucode-tool
 +
 +# if enabled, use the microcode added initrd

I don't see any conditional tests for the if enabled part of the comment.

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

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

[Burton, Ross]

On 17 September 2014 15:20,  sreeju.armughanx.selva...@intel.com wrote:
 Added MACHINE_EXTRA_RRECOMMENDS to include dpdk v1.7.0 support
 for romley machiine, so that dpdk will be enabled by default
 for Romley. Also included the dpdk example package, so that
 user can use example apps to exercise the DPDK libraries.

I went through this with the guy who submitted the 1.7 recipes.

On their own, the DPDK packages are useless as the user needs to
compile their application with them.  What you're basically doing is
forcing a library onto *every* image for that machine, even ones that
don't want to use DPDK.  Please don't do that.

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

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

[Burton, Ross]

On 17 September 2014 20:44,  nitin.a.kam...@intel.com wrote:
 As per request from Tom, allow disabling of the Intel microcode
 feature for meta-intel BSPs.

 If one adds this line to local.conf while build a meta-intel BSP,
 the microcode feature will be disabled for the build target.

 DISABLE_INTEL_MICROCODE = 1

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

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

Re: [meta-intel] (no subject)

[Burton, Ross]

On 16 September 2014 12:35, Stuart Weaver stuart.wea...@datapath.co.uk wrote:
 I've just made a fresh Yocto/meta-intel repository and created an image based
 on core-image-sato for valleyisland-32.

What release or git revision of poky/yocto/oe-core are you using?  The
microcode support in git master of meta-intel needs some changes that
were made to oe-core master, so if you're using a release of Poky (or
oe-core) but git master of meta-intel then this is the sort of failure
I'd expect to see.

If you're stuck with a release of oe-core/poky then use the
corresponding branch in meta-intel, and cherry-pick anything that you
need from master.

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

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

[Burton, Ross]

On 18 September 2014 03:21, Ong, Boon Leong boon.leong@intel.com wrote:
 On their own, the DPDK packages are useless as the user needs to compile
 their application with them.  What you're basically doing is forcing a 
 library onto
 *every* image for that machine, even ones that don't want to use DPDK.
 Please don't do that.

 So, reading from your feedback, I think that you are suggesting to create 
 bbappend file for each of the target image type
 (core-image-sato  core-image-sato-sdk) with IMAGE_INSTALL += dpdk 
 dpdk-examples ...
 Just want to be sure we get your idea correctly.

 These are the two images that CID customers are using from Yocto Project.

I'm suggesting that nobody will be taking e.g core-image-sato and be
able to work out of the box with dpdk installed, as they'll need a
toolchain to build their own application against dpdk. Let's just not
install it in the images, and a user will either write a recipe for
their image or create a SDK image to which they can trivially add
dpdk.

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

Re: [meta-intel] [PATCH V2 1/3] meta-intel/common: Add include file for DPDK

[Burton, Ross]

On 26 September 2014 07:58, Selvaraj, Sreeju ArmughanX
sreeju.armughanx.selva...@intel.com wrote:
 Is this patch fine ? Do you have any feedback on this.

It seems reasonable to me.

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

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

[Burton, Ross]

On 26 September 2014 10:34, Selvaraj, Sreeju ArmughanX
sreeju.armughanx.selva...@intel.com wrote:
 Is This patch fine ?

I didn't look at this in detail, but the patches need to have both
Signed-off-by and Upstream-Status tags
(http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations).

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

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

[Burton, Ross]

On 10 October 2014 22:18, Darren Hart dvh...@linux.intel.com wrote:
 The primary issue with eliminating the defaults from intel-corei7-64 and
 providing the default via machinesetuptool, is we then make
 machinesetuptool a requirement for that BSP for basic functionality. That
 isn't acceptable in my opinion.

Agreed.  The BSP should have sane defaults, and if a particular user
wants to use machinesetup for a particular machine then that can
override the defaults.  But there should be sane (has keyboard, no
touchscreen) defaults for the intel BSP.

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

Re: [meta-intel] State of GPU/QuickSync support without X11 on yocto

[Burton, Ross]

On 17 October 2014 12:04, Volker Vogelhuber
v.vogelhu...@digitalendoscopy.de wrote:
 So the open source driver fully supports quick sync and opengl in hardware
 as well?
 If yes I guess using gstreamer and mesa packages, right?

I'm heading into guesswork here...  Intel QuickSync is basically
hardware-assisted video encode/decode, and this is exposed on Intel HW
in traditional Linux through libva, which GStreamer can use.  So
yes, vaapi-intel-drivers - libva - gstreamer-vaapi should work fine,
and is in meta-intel.

For GL, yes the stock kernel and Mesa will work.

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

Re: [meta-intel] Packages needed for gstreamer h264 libva encoding

[Burton, Ross]

On 20 October 2014 16:25, Volker Vogelhuber
v.vogelhu...@digitalendoscopy.de wrote:
 Currently I added gstreamer1.0, gstreamer-vaapi-1.0 and libva-intel-driver
 to the image recipe, but it does not seem to add any h264 encoder at all.

The decoder is in your hardware, so there's nothing to install.
You'll probably want to install the full set of GStreamer elements
(the gstreamer -meta packages depend on all of them for convenience)
so you don't have problems with container decoding, but the playbin
element should automatically do hardware-assisted decoding and colour
space conversion if the VA pieces are all installed.

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

Re: [meta-intel] [PATCH] intel-gpu-tools: add missing build-dependencies

[Burton, Ross]

On 4 November 2014 16:53, Darren Hart dvh...@linux.intel.com wrote:

 Was this manifesting as a racy build failure?


Nope, new QA warnings.  Presumably it's gone unnoticed as only the
autobuilder does world builds, and nobody bothers checking those for
warnings.

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

Re: [meta-intel] [PATCH v2 0/1] DPDK update

[Burton, Ross]

On 6 November 2014 16:22, Tom Zanussi tom.zanu...@linux.intel.com wrote:

 As there hasn't been any action on the various problems plaguing the
 DPDK recipes and we're coming up on a release, move them out of
 common/, at minimum.

 v2: Add COMPATIBLE_MACHINE for romley|romley-ivb


Acked.

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

Re: [meta-intel] [MinnowBoard][PATCH] systemd: Conditionally add network file for systemd

[Burton, Ross]

On 19 November 2014 22:00, Darren Hart dvh...@linux.intel.com wrote:

 It seems to be a tricky one as the network interfaces are BSP-specific.
 This is a follow-on to:

 $ git show e3718d2
 commit e3718d24e9d2bbdac00d6f1ebd8cbe2894981e4e
 Author: Sujith H sujith_harida...@mentor.com
 Date:   2014-07-30

 systemd: Network configuration for minnow board

 Adding network configuration for minnow board.

 Which adds:

 +++ b/recipes-core/systemd/systemd/10-dhcp.network
 @@ -0,0 +1,5 @@
 +[Match]
 +Name=en*
 +
 +[Network]
 +DHCP=yes

 This is specific to Minnow having an en0 interface, while other boards
 might have eth0, or some other name. The DHCP bit is arguably a DISTRO
 policy however.

 Perhaps a more generic version which matches a host of common names
 would be better and we could drop this rather basic one from meta-minnow
 all together.


Considering that oe-core disables networkd, this can still be considered a
distro-specific tweak. And isn't en* the standard name for ethernet devices
on all hardware when systemd is renaming network devices, so this isn't
BSP-specific?

(
http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20
)

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

Re: [meta-intel] [PATCH 0/3] Upgrades for comply Intel Graphics Stack Release 2014Q3

[Burton, Ross]

On 22 December 2014 at 17:53, Aníbal Limón anibal.li...@linux.intel.com
wrote:

 Any comment?


These have all been merged into master already.

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

Re: [meta-intel] [PATCH 0/3] Upgrades for comply Intel Graphics Stack Release 2014Q3

[Burton, Ross]

On 22 December 2014 at 23:51, Aníbal Limón anibal.li...@linux.intel.com
wrote:

 I think these confusion is related to the same subject in the email, sorry
 about it.


Yeah, that caused gmail to merge them together for me, thanks google!
Sometimes GMail really isn't great for patch review, sorry for the
confusion.

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

Re: [meta-intel] GStreamer 1.0 and VAAPI

[Burton, Ross]

On 9 January 2015 at 20:58, Chris Tapp opensou...@keylevel.com wrote:

 I think I've got it working (well, building and in the image!), but it
 looks like GStreamer doesn't like my pipeline for a DVB-T stream (mpegts)
 as this starts with a few empty frames which causes libva to terminate the
 pipeline...


I can't really help with this, but #gstreamer will be able to.

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

Re: [meta-intel] GStreamer 1.0 and VAAPI

[Burton, Ross]

On 7 January 2015 at 17:43, Chris Tapp opensou...@keylevel.com wrote:

 Ignore gst-va-intel, all you need is gstreamer-vaapi-1.0 to get GStreamer
 1.0 to do VAAPI.


 Thanks. What about va-intel and libva-intel-driver - looks like I need
 these?


Erm, yeah, libva-intel-driver might be useful if you want it to actually
work, I should have mentioned that!


 That said 1.0 and 0.10 shouldn't be conflicting, what were the errors?


 I don't have the exact message to hand at the moment, but it was something
 to do with 0.10 shared libs being installed with the same name as the
 corresponding 1.0 libs. The 0.10 then took precedence as they were
 installed later.

 0.10 was pulled in due to some RDEPENDS in gst-va-intel (e.g. for
 gst-plugins-good-isomp4, which is 0.10 specific).


Ah right, that's the problem where private libraries in different
directories with the same basename get confused for the same library.
Known problem and I thought there was a workaround.  I'll dig.

For what it's worth I plan on getting the va metapackages removed from
meta-intel now as they're pointless - they were created to abstract the
choice between EMGD and gst-vaapi but EMGD doesn't exist in meta-intel any
more.

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

Re: [meta-intel] GStreamer 1.0 and VAAPI

[Burton, Ross]

On 2 January 2015 at 22:35, Chris Tapp opensou...@keylevel.com wrote:

 As I'm using GStreamer 1.0, I'm pulling gstreamer-vaapi-1.0 in to my
 image. How does gst-va-intel relate to this? I've tried adding this to my
 image as well, but that results in GStreamer 0.10 being pulled in,
 resulting in installation conflicts with the 1.0 libraries.


Ignore gst-va-intel, all you need is gstreamer-vaapi-1.0 to get GStreamer
1.0 to do VAAPI.

That said 1.0 and 0.10 shouldn't be conflicting, what were the errors?

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

Re: [meta-intel] The gma500_gfx driver, X server, OpenGL

[Burton, Ross]

On 17 March 2015 at 00:56, Erik Bolton ebol...@agjunction.com wrote:

 2)  Does the gma500_gfx driver support OpenGL/GLX at all? My
 assumption was that Intel wouldn’t drop the EMGD from the yocto BSPs that
 use this GPU if the new kernel driver didn’t have SOME 3D acceleration
 support, but now I’m not sure. I can see GL and GLES libs in /usr/lib, but
 I can’t tell who is providing them.

 3)  I need hardware accelerated OpenGL, so, assuming the gma500_gfx
 is no good, do you guys think I should try and hack the EMGD driver back
 into the 1.7.1 BSP and disable the gma500_gfx driver or take another route?


To the first questions in each point:

(2) no
(3) yes

Sadly EMGD is a mostly-binary driver with a complicated kernel driver that
isn't supported for the kernels that we were updating to.  To use EMGD
you'll need to copy the recipes from meta-intel before they were deleted
and the corresponding kernel recipes from oe-core so the kernel portions
work correctly.

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

Re: [meta-intel] Core i5-4460S H81 machine

[Burton, Ross]

On 26 March 2015 at 01:12, Lai Eddy eddy.lai...@gmail.com wrote:

 I have a Core i5-4460S board with H81 chipset
 what MACHINE should I set in local.conf?
  intel-corei7-64? or genericx86-64 , 


intel-corei7-64.

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

Re: [meta-intel] [PATCH 1/2] libva: Update to 1.5.0

[Burton, Ross]

On 27 February 2015 at 17:23, Darren Hart dvh...@linux.intel.com wrote:

 They are under test on wrath now. Will be on the AB shortly.


What I should have mentioned is that I needed to upgrade libva
libva-intel-driver and gstreamer-vaapi before video playback started to
work again.  Its like it bitrots on its own, as every time we upgrade these
we confirm it works...

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

Re: [meta-intel] [PATCH 1/2] libva: Update to 1.5.0

[Burton, Ross]

On 27 February 2015 at 16:40, Darren Hart dvh...@linux.intel.com wrote:

 Whenever submitting a patch, please provide a commit message. Even if
 it's trivial, there is something to be said. Why should we do the
 update? Does it support new hardware? A particularly relevant feature?
 If not, knowing it's just an update is useful information. Which
 machines are impacted and what tessting has been performed (as Nitin
 pointed out). In general, if it's worth submitting, it's worth documenting.


1.5.0 plays videos, the previous release doesn't.  Hooray the VA-API stack
for being incredibly fragile.

Note that I sent the same upgrades yesterday but Anibal beat me by a good
two weeks so merge his.

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

Re: [meta-intel] [PATCH] xf86-video-mga: Upgrade 1.6.2 - 1.6.4

[Burton, Ross]

On 11 May 2015 at 19:20, Saul Wold s...@linux.intel.com wrote:

 I think that this is probably in prep for the 1.17 upgrade.  We are
 currently at 1.16.3 so we would not see the issue he is seeing. I think
 that we should take this patch.


That's right.

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

Re: [meta-intel] Why meta-intel never specify the Intel-SNA as a primary Xorg driver in common folder ?

[Burton, Ross]

On 16 April 2015 at 12:48, Ong, Boon Leong boon.leong@intel.com wrote:

 Yes, some CID platform which is address data-center processor/chipset uses
 external PCIe VESA graphic card.


And there's a number of Atom platforms that use GMA500/600 graphics and so
need the modesettings driver.

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

Re: [meta-intel] Why does libva-egl RDEPEND on libva-x11

[Burton, Ross]

On 1 July 2015 at 00:46, Tobias Olausson tobias.olaus...@pelagicore.com
wrote:
 1) Is there a reference system commonly used to verify changes? I built
core-image-weston for corei7-64 with meta-intel on top of poky, would that
be fitting?

That would be a suitable build test, but actually exercising the VA-API
driver under EGL would be better.

 2) I'm not exactly sure if the dependency should be removed completely or
changed to RDEPENDS_${PN}-egl =+ ${PN}. Noticing that libva-wayland has
no such dependency, but any suggestions or pointers are welcome.

The link to PN will be generated automatically if required, so removing the
line is likely sufficient.

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

Re: [meta-intel] [PATCH v3] intel-gpu-tools: upgrade to version 1.11

[Burton, Ross]

On 12 August 2015 at 16:17, Saul Wold s...@linux.intel.com wrote:

 If you are running on a system with bash the /bin/sh will point to bash so
 there is no real change, the real test is to install these tools on a
 system without Bash and ensure they work.


Or run checkbashisms, or just read the scripts.

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

Re: [meta-intel] [PATCH][RFC] Deprecate older Platform specific BSPs

[Burton, Ross]

On 23 August 2015 at 01:18, Saul Wold s...@linux.intel.com wrote:

 The intel-core* BSPs supercede these older BSPs therefore it's time
 to remove these older platform specific bsps.


Deprecate isn't the word I'd use for deleting them, but I agree with
deleting them entirely.

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

Re: [meta-intel] Why does libva-egl RDEPEND on libva-x11

[Burton, Ross]

On 29 June 2015 at 23:32, Tobias Olausson tobias.olaus...@pelagicore.com
wrote:

 libva [1] includes libva-x11, libva-glx, libva-egl, libva-wayland etc.
 What I cannot understand is why libva-egl depends on libva-x11. Looking at
 configure.ac in the git repo for libva [2] it makes even less sense,
 since there are no dependencies for x11 on the egl option. Is there
 something here I'm missing, or should the dependency really be removed?


You're right, that doesn't look right.  You're in the ideal position to
remove that dependency and verify that it works correctly still.  If it
works, can you send a patch please?

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

Re: [meta-intel] [PATCH 1/3] gstreamer-vaapi: upgrade to 0.6.0 (v2)

[Burton, Ross]

On 11 August 2015 at 11:49, Lim Siew Hoon siew.hoon@intel.com wrote:

 +DEPENDS = libva libva-intel-driver


Is that an actual build dependency?  If it's a runtime dependency then you
mean RDEPENDS, and isn't gstreamer-vaapi driver-agnostic (although mainly
tested against the Intel driver)?

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

Re: [meta-intel] CrownBay EMGD acceleration for Daisy 1.6.3

[Burton, Ross]

On 13 August 2015 at 17:49, Chad Bishop chad.a.bis...@gmail.com wrote:

 The EMGD documentation for v1.18 of the driver speaks to EMGD support for
 Wayland / Weston.  However the details are specific to Meego.

 I am writing to inquire as to whether the meta-intel CrownBay BSP provided
 for daisy can also support this configuration.


A very old dated snapshot of Wayland/Weston from before they even make a
1.0 release should work, but you'll need the exact snapshot.

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

Re: [meta-intel] [PATCH] bsps: update meta SRCREVs

[Burton, Ross]

On 23 July 2015 at 23:38, Bruce Ashfield bruce.ashfi...@windriver.com
wrote:

 You need the patches that I sent to oe-core that split the meta data
 from the kernel repository (see zedd/kernel in poky-contrib).

 The revs must exist in the yocto-kernel-cache repository. It's a
 chicken and egg situation. This broke under test when my series is
 applied, but can't merge until that series goes into oe-core.


For now, I pushed a branch to meta-intel-contrib (ross/kernel) that has
this patch for testing with oe-core master-next.  Obviously the actual
merge to oe-core and meta-intel needs to be orchestrated somehow so there's
not a several day lag between the commits.

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

Re: [meta-intel] [fido][PATCH 2/2] common/intel-gpu-tools: Modularize and make X11 dependency optional

[Burton, Ross]

On 20 October 2015 at 09:43, Joonas Lahtinen <
joonas.lahti...@linux.intel.com> wrote:

> +require intel-gpu-tools.inc
>

I'm a big fan of not having inc files unless there's a clear need.  What
sort of extending are you doing, and could they not be done with bbappends
or distro PACKAGECONFIG assignments?

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

Re: [meta-intel] [PATCH] intel-core2-32: Fix-up SERIAL_CONSOLES list

[Burton, Ross]

On 30 September 2015 at 02:05, Saul Wold  wrote:

> -MACHINE_EXTRA_RRECOMMENDS += "linux-firmware"
> +MACHINE_EXTRA_RRECOMMENDS += "linux-firmware \
> +  gma500-gfx-fix \
> + "
>

Spurious hunk that shouldn't have been in this patch I guess?

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

Re: [meta-intel] Framebuffer support for Atom

[Burton, Ross]

On 18 June 2016 at 12:10, Jörg Wille  wrote:

> Does yocto support any graphics driver for Atom (E3845;  HD Graphics - Bay
> Trail) to use framebuffer driver with hardware acceleration OpenGL ES using
> EGL?


Also the standard open driver works, you don't need to use EMGD.

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

Re: [meta-intel] [PATCH] gstreamer-vaapi: Update 0.6.1-> 0.7.0

[Burton, Ross]

On 25 January 2016 at 22:48, Saul Wold  wrote:

> Please use git mv instead of deleting and creating update recipes, that
> way we preserve the history.
>

Actually git doesn't track moves, only additions and deletions.  What we
want here is -M being passed to send-email or format-patch, which hopefully
will then notice that the files are renamed and edited.

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

Re: [meta-intel] RFC to migrate meta-intel/meta-isg -> meta-intel-isg

[Burton, Ross]

On 10 March 2016 at 17:48, Saul Wold  wrote:

> I would like to hear from the various users of meta-intel and meta-
> intel/meta-isg about moving meta-isg into it's own repo that would be
> named meta-intel-isg and meta-intel-isg-bsp to distinguish between the
> sofware and the BSPs.  The hope is that most of the BSP configuration
> will come from the meta-intel BSPs to reduce fragmentation. Only
> special cases will land in the isg-bsp layer.  Most changes should come
> in via linux-yocto kernel repo and via intel-core* BSPS.
>

The split sounds sensible to me.

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

Re: [meta-intel] [PATCH] canterbury-corpus: Use base_libdir in FILES

[Burton, Ross]

On 23 May 2016 at 12:41, Jussi Kukkonen  wrote:

> -FILES_${PN} = "/lib/firmware/*"
> +FILES_${PN} = "${base_libdir}/firmware/*"
>

If these files are being loaded by the kernel firmware loader then /lib is
right and the rest of the recipe is wrong.

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

Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2

[Burton, Ross]

On 26 July 2016 at 21:55, Trevor Woerner  wrote:

> To be honest, it's the comment that's confusing me:
>
> # opengl packageconfig factored out to make it easy for distros
> # and BSP layers to pick either (desktop) opengl, gles2, or no GL
>
> In any case, I've sent a patch. If it's wrong, I'm sure someone will point
> it
> out:
>
> https://patchwork.openembedded.org/patch/127991/
>

Ah, interesting.  I didn't actually look at the recipe... :/

GLES is the more universal option, and GL is definitely only specific to
certain pieces of hardware, so I can see why the recipe takes this approach.

The alternative would be to see if gst-vaapi can be told to use GLES
instead of GL out of the box, as that will run on far more hardware without
modification.

(GL being "OpenGL on X11" which is only really accelerated on x86 with
certain graphics cards, and if GL is being emulated in software then
there's certainly no point in using it for acceleration!)

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

Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2

[Burton, Ross]

On 26 July 2016 at 20:55, Trevor Woerner  wrote:

> Okay, I'm looking into what needs to get done.
>

It's just a matter of using base_contains() on DISTRO_FEATURES in the
PACKAGECONFIG assignment in oe-core, there's plenty of examples across the
layer.

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

Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2

[Burton, Ross]

On 27 July 2016 at 15:44, Scott D Phillips 
wrote:

> If I understand right you have 'opengl' in your DISTRO_FEATURES
> and do not have 'gles2'.  Is that right?  I think in that case
> 'opengl' should be set in the PACKAGECONFIG for plugins-bad
> so that the gstgl library can get built for you.
>

I just built gst-vaapi and interestingly my -bad built the opengl plugin
despite PACKAGECONFIG saying not to.  I suspect there's a non-determinism
problem here, and will dig a bit further.

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

Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2

[Burton, Ross]

On 27 July 2016 at 23:09, Trevor Woerner  wrote:

> PACKAGECONFIG_pn-gstreamer1.0-plugins-bad = "opengl"
>

You meant to put _append in there, as there's a large default value that
you're overriding.

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

Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2

[Burton, Ross]

Hi Trevor,

On 26 July 2016 at 19:24, Trevor Woerner  wrote:

> It seems as though adding:
>
> PACKAGECONFIG_pn-gstreamer1.0-plugins-bad = "opengl"
>
> to local.conf fixes the issue. But my distro does contain opengl as part of
> its DISTRO_FEATURES. So I'm not entirely sure why this configuration option
> wouldn't turn itself on by default :-(
>

Going back to this, it appears that for me at least with the standard
configuration gstreamer-gl is always built, and enabling opengl simply adds
more pieces to the gstreamer-gl library: out of the box it builds a
gstreamer-gl which links to GLES.

Do you have some local/distro configuration which is fiddling the
PACKAGECONFIG for gstreamer-plugins-bad, or does your DISTRO_FEATURES not
contain opengl?

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

Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2

[Burton, Ross]

On 28 July 2016 at 16:57, Trevor Woerner  wrote:

> PACKAGECONFIG_pn-gstreamer1.0-plugins-bad_append = " opengl"
>

You mean:

PACKAGECONFIG_append_pn-gstreamer1.0-plugins-bad

(I remember that append is 'a' so at the beginning of the alphabet, so at
the beginning of the operations.  This doesn't work too well for _remove,
but just remember that is paired with _append)

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

Re: [meta-intel] [PATCH] thermald: Add thermal daemon utility

[Burton, Ross]

On 7 July 2016 at 07:56, Yong Li  wrote:

> +SYSTEMD_AUTO_ENABLE_${PN} = "enable"
>

This is the default so you can remove it.


> +COMPATIBLE_MACHINE = "intel-corei7-64|intel-core2-32|intel-quark|edison"
>

Instead of listing machines (which stops working the moment someone creates
a new one), use  COMPATIBLE_HOST:

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

This will ensure the recipe can work on all 32-bit and 64-bit x86 machines.

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

Re: [meta-intel] [PATCH] dpdk: Update SRC_URI checksums

[Burton, Ross]

On 5 December 2016 at 23:26, Khem Raj  wrote:

> -SRC_URI[dpdk.md5sum] = "f51ffc862a4f57b0030ca5d7ff07fef0"
> -SRC_URI[dpdk.sha256sum] = "8098b3542b4c78d28bde5f4eba57d4
> ee929fffaaa941b7afd2b881eae0b45c00"
> +SRC_URI[dpdk.md5sum] = "24f057ec64c277fbb181ff29569f6844"
> +SRC_URI[dpdk.sha256sum] = "cf2ef6faf8cd056abbbebba779b785
> 0eb3f79edd0d91767bcdbc216a2cde4fd1"
>

The autobuilder has been hitting this but I forgot to talk to Saul.

Saul, who maintains these recipes currently?  Can we get an acknowledgement
that they replaced the tarball on purpose and we haven't detected a
successful hack, and ideally that the DPDK team promises not to replace
tarballs again?

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

Re: [meta-intel] [OE-core] [PATCH 2/2] gstreamer1.0-vaapi: Import from meta-intel

[Burton, Ross]

On 6 December 2016 at 09:57, Ylinen, Mikko  wrote:

> This suggests the versions should be kept in sync with the gstreamer
> versions:
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/?id=
> 3f51f61efe93c104ba7996f54f381c6c1a5e6546
>

Khem sent a GStreamer upgrade a few days ago, so they'll all be merging at
once.  gst-vaapi 1.8 doesn't build with gst 1.10 anyway.

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

Re: [meta-intel] [PATCH] conf: set recipe maintainers

[Burton, Ross]

On 15 May 2017 at 00:53, Paul Eggleton 
wrote:

> I haven't actually checked, but I think there may be a slight problem with
> this in that include/require pick up things using BBPATH, so this file
> having
> the same name as the one in meta-poky might mask that one out depending on
> the
> order of BBLAYERS.
>

Hm.  In testing it Did The Right Thing, but I didn't try changing
BBLAYERS.  Swapping the order of meta-poky and meta-intel in BBLAYERS
doesn't change what files get included, so this appears to be mostly
working at least.

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

Re: [meta-intel] [PATCH] turbostat: add the recipe of turbostat

[Burton, Ross]

Shouldn't the kernel recipe be building this?

Ross

On 16 May 2018 at 09:05, Hongzhi.Song  wrote:
> From: Hongzhi Song 
>
> It is an efficient tool to reflect the status of X86 processors.
> Turbostat reports processor topology, frequency, idle power-state
> statistics, temperature and power on X86 processors.
>
> Signed-off-by: Hongzhi Song 
> ---
>  recipes-kernel/turbostat/turbostat_3.4.bb | 56 
> +++
>  1 file changed, 56 insertions(+)
>  create mode 100644 recipes-kernel/turbostat/turbostat_3.4.bb
>
> diff --git a/recipes-kernel/turbostat/turbostat_3.4.bb 
> b/recipes-kernel/turbostat/turbostat_3.4.bb
> new file mode 100644
> index 000..ec789c1
> --- /dev/null
> +++ b/recipes-kernel/turbostat/turbostat_3.4.bb
> @@ -0,0 +1,56 @@
> +#
> +# Copyright (C) 2013 Wind River Systems, Inc.
> +#
> +SUMMARY = "Frequency and Idle power monitoring tools for Linux"
> +
> +DESCRIPTION = "The turbostat tool allows you to determine the actual \
> +processor frequency and idle power saving state residency on supported \
> +processors."
> +
> +LICENSE = "GPLv2"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> +
> +
> +PR = "r7"
> +
> +COMPATIBLE_HOST = '(x86_64.*|i.86.*)-linux'
> +
> +DEPENDS = "virtual/kernel"
> +
> +do_fetch[noexec] = "1"
> +do_unpack[noexec] = "1"
> +do_patch[noexec] = "1"
> +
> +# This looks in S, so we better make sure there's
> +# something in the directory.
> +#
> +do_populate_lic[depends] = "${PN}:do_configure"
> +
> +
> +EXTRA_OEMAKE = '\
> +CC="${CC}" \
> +   'CFLAGS=-Wall -I${STAGING_KERNEL_DIR}/arch/x86/include/uapi 
> ${LDFLAGS}' \
> +   '
> +
> +# If we build under STAGING_KERNEL_DIR, source will not be put
> +# into the dbg rpm.  STAGING_KERNEL_DIR will exist by the time
> +# do_configure() is invoked so we can safely copy from it.
> +#
> +do_configure_prepend() {
> +   mkdir -p ${S}
> +   cp -r ${STAGING_KERNEL_DIR}/arch/x86/include/asm/msr-index.h ${S}
> +   cp -r ${STAGING_KERNEL_DIR}/arch/x86/include/asm/intel-family.h ${S}
> +   cp -r ${STAGING_KERNEL_DIR}/tools/power/x86/turbostat/* ${S}
> +   cp -r ${STAGING_KERNEL_DIR}/COPYING ${S}
> +}
> +
> +do_compile() {
> +   sed -i 's#MSRHEADER#"msr-index.h"#' turbostat.c
> +   sed -i 's#INTEL_FAMILY_HEADER#"intel-family.h"#' turbostat.c
> +   sed -i 's#\$(CC) \$(CFLAGS) \$< -o \$(BUILD_OUTPUT)/\$@#\$(CC) 
> \$(CFLAGS) \$(LDFLAGS) \$< -o \$(BUILD_OUTPUT)/\$@#' Makefile
> +   oe_runmake STAGING_KERNEL_DIR=${STAGING_KERNEL_DIR}
> +}
> +
> +do_install() {
> +   oe_runmake DESTDIR="${D}" install
> +}
> --
> 2.11.0
>
> --
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

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

[Burton, Ross]

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

Ross

On 6 February 2018 at 21:43, Cal Sullivan 
wrote:

> Getting a strange error when building for x32:
>
> | checking for pkg-config... 
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x32/build/build/tmp/work/x86_64_x32-poky-linux-gnux32/intel-vaapi-driver/2.0.0-r0/recipe-sysroot-native/usr/bin/pkg-config
> | configure: WARNING: using cross tools not prefixed with host triplet
> | checking pkg-config is at least version 0.9.0... yes
> | checking for libdrm >= 2.4.52... yes
> | checking for intel-gen4asm >= 1.9... no
> | checking for intel-gen4asm... no
> | checking for git... 
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x32/build/build/tmp/hosttools/git
> | checking for libva >= 1.0.0... no
> | configure: error: Package requirements (libva >= 1.0.0) were not met:
> |
> | Requested 'libva >= 1.0.0' but version of libva is 0.40.0
> |
> | Consider adjusting the PKG_CONFIG_PATH environment variable if you
> | installed software in a non-standard prefix.
> |
> | Alternatively, you may set the environment variables LIBVA_DEPS_CFLAGS
> | and LIBVA_DEPS_LIBS to avoid the need to call pkg-config.
> | See the pkg-config man page for more details.
>
> Initially I was thinking that a host libva was getting picked up, but libva 
> 0.40 doesn't appear to exist.
>
> Thanks,
> Cal
>
> On 02/06/2018 12:38 AM, Anuj Mittal wrote:
>
> Major changes:
>
> * Bump version to 2.0.0
> * Add support for Coffee Lake (aka. CFL)
>   - Decoding: H.264/MPEG-2/VC-1/JPEG/VP8/HEVC/HEVC 10-bit/VP9/VP9 10-bit
>   - Encoding: H.264/MPEG-2/JPEG/VP8/VP9/HEVC/HEVC 10-bit/AVC low power 
> CQP/CBR/VBR mode
>   - VPP: CSC/scaling/NoiseReduction/Deinterlacing{Bob, MotionAdaptive, 
> MotionCompensated}/ColorBalance/STD
> * Add support for H264 FEI
> * Add support for HEVC ROI encoding
> * Add support for intensity compensation for VC-1 decoding
> * Improve the quality of the H264 encoder on BDW/BSW
> * Improve the CSC performance between I420/NV12/P010/YUY2/VYUY format
> * Improve the performace of va{Get, Put}Image for I420/NV12/P010/YUY2/VYUY 
> format
> * Fix image corruption for VP9 decoding
> * Fix race condition in wayland support
> * Fix ROI support in VDEnc support
> * Fix corrupted stream when using VDEnc CBR/VBR
> * Fix GCC 7.1.1 warnings/errors
> * Update the shader for HEVC encoding
>
> The upstream package name now is intel-vaapi-driver instead of 
> libva-intel-driver.
>
> Updated to point to release tarball instead of git. Also, changed
> the URLs to point to new project page.
>
> Signed-off-by: Anuj Mittal  
> ---
>  conf/include/maintainers.inc |  2 +-
>  ...intel-driver_1.8.3.bb => intel-vaapi-driver_2.0.0.bb} | 16 
> +++-
>  recipes-multimedia/libva/va-intel.bb |  4 ++--
>  3 files changed, 10 insertions(+), 12 deletions(-)
>  rename recipes-multimedia/libva/{libva-intel-driver_1.8.3.bb => 
> intel-vaapi-driver_2.0.0.bb} (62%)
>
> diff --git a/conf/include/maintainers.inc b/conf/include/maintainers.inc
> index 64896c3..0ab61ab 100644
> --- a/conf/include/maintainers.inc
> +++ b/conf/include/maintainers.inc
> @@ -8,7 +8,7 @@ RECIPE_MAINTAINER_pn-intel-gpu-tools = "Anuj Mittal 
>  "
>  RECIPE_MAINTAINER_pn-intel-microcode = "California Sullivan 
>  "
>  RECIPE_MAINTAINER_pn-core-image-minimal-initramfs = "California Sullivan 
>  "
>  RECIPE_MAINTAINER_pn-iucode-tool = "California Sullivan 
>  "
> -RECIPE_MAINTAINER_pn-libva-intel-driver = "Anuj Mittal 
>  "
> +RECIPE_MAINTAINER_pn-intel-vaapi-driver = "Anuj Mittal 
>  "
>  RECIPE_MAINTAINER_pn-libyami = "Anuj Mittal  
> "
>  RECIPE_MAINTAINER_pn-libyami-utils = "Anuj Mittal  
> "
>  RECIPE_MAINTAINER_pn-linux-intel = "California Sullivan 
>  "
> diff --git a/recipes-multimedia/libva/libva-intel-driver_1.8.3.bb 
> b/recipes-multimedia/libva/intel-vaapi-driver_2.0.0.bb
> similarity index 62%
> rename from recipes-multimedia/libva/libva-intel-driver_1.8.3.bb
> rename to recipes-multimedia/libva/intel-vaapi-driver_2.0.0.bb
> index 72451c0..e651107 100644
> --- a/recipes-multimedia/libva/libva-intel-driver_1.8.3.bb
> +++ b/recipes-multimedia/libva/intel-vaapi-driver_2.0.0.bb
> @@ -1,10 +1,10 @@
>  SUMMARY = "VA driver for Intel G45 & HD Graphics family"
> -DESCRIPTION = "libva-driver-intel is the VA-API implementation \
> +DESCRIPTION = "intel-vaapi-driver is the VA-API 

Re: [meta-intel] Unable to build yocto for Intel Mohon Peak CRB

[Burton, Ross]

On 1 August 2018 at 15:13, Dhanasekar Jaganathan
 wrote:
> OSError: [Errno 13] Permission denied:
> '/home/server/Dhanasekar/Server-BIOS/yocto/poky/build/cache'

For whatever reason you don't have permission to write to this folder,
but the build can't even start without that.  Check your permissions.

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

Re: [meta-intel] Bare minimum configuration

[Burton, Ross]

On 18 March 2018 at 22:56, Tim Jones  wrote:

> Hi Folks,
>
> I've now gotten a good feel for how Yocto puts things together, but I'm
> running into a wall trying to find the package selections.  What I'm
> shooting for is a meta-intel build with the hardware as provided, but I
> want to remove everything from the package list except for a few specific
> items - busybox, a custom python configuration, dhcp tools, vim, init, and
> grub.
>
> Is there a document that describes paring things down to this level?
>

If you really care about image size then core-image-minimal is an example
image which just about boots and not much else, from which you can add more
packages as required.

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

Re: [meta-intel] ac_nonexistent.h error in do_configure

[Burton, Ross]

On Wed, 3 Oct 2018 at 09:40, Anuj Mittal  wrote:
> This check is supposed to fail. This is a sanity test, that header isn't
> supposed to exist and autoconf expects this compilation error. I don't
> think this is the actual point of failure.

What would be useful is the output of 'bitbake core-image-x11', and if
that specifies a task that failed, the complete log for that task (in
tmp/work).

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

Re: [meta-intel] ERROR: - package networkmanager-1.10.6-r0.aarch64 conflicts with connman provided by connman-1.35-r0.aarch64

[Burton, Ross]

You'll have to not install either connman or network manager.

Ross

On Tue, 15 Jan 2019 at 05:18, srinivasan  wrote:
>
> Dear Yocto experts,
>
> I am seeing the below error when I am trying to integrate the
> "fsl-image-validation-imx.bb" into my custom yocto build and trigger
> the build using "bitbake custom-image-debug-imx8.bb", I somewhat feel
> networkmanager is conflicting with conman, could you please let me
> know how this issue can be resolved?
>
> I have attached the recipe files for your information
>
> Error:
>
> ERROR: custom-image-debug-imx8-1.0-r0 do_rootfs: Could not invoke dnf.
> Command 
> '/home/user/test/os/build_fsl-image-validation-imx/tmp/work/imx8mmevk-poky-linux/custom-image-debug-imx8/1.0-r0/recipe-sysroot-native/usr/bin/dnf
> -y -c 
> /home/user/test/os/build_fsl-image-validation-imx/tmp/work/imx8mmevk-poky-linux/custom-image-debug-imx8/1.0-r0/rootfs/etc/dnf/dnf.conf
> --setopt=reposdir=/home/user/test/os/build_fsl-image-validation-imx/tmp/work/imx8mmevk-poky-linux/custom-image-debug-imx8/1.0-r0/rootfs/etc/yum.repos.d
> --repofrompath=oe-repo,/home/user/test/os/build_fsl-image-validation-imx/tmp/work/imx8mmevk-poky-linux/custom-image-debug-imx8/1.0-r0/oe-rootfs-repo
> --installroot=/home/user/test/os/build_fsl-image-validation-imx/tmp/work/imx8mmevk-poky-linux/custom-image-debug-imx8/1.0-r0/rootfs
> --setopt=logdir=/home/user/test/os/build_fsl-image-validation-imx/tmp/work/imx8mmevk-poky-linux/custom-image-debug-imx8/1.0-r0/temp
> --nogpgcheck install alsa-server alsa-tools alsa-utils apt apt-repo
> bash basicquick bc binutils binutils-symlinks bmap-tools-git
> build-config bzip2 cmake coreutils crashme crda dfu-util diffutils dnf
> dnsmasq ethtool file libfreetype6 gdb gdbserver gettext git
> glibc-gconv-utf-32 gnupg libharfbuzz0 hidapi hostapd htop iperf3 iw
> kernel-dev kernel-devsrc kernel-modules ldd libasound liberation-fonts
> libfftw libfftwf libjack libjpeg62 libpng16-16 libtool libxerces-c
> libsensors4 lmsensors-sensors lsof lttng-modules make memtester
> merge-files nano networkmanager ni-isolcpus ninja openssl
> packagegroup-base-extended packagegroup-core-boot
> packagegroup-core-full-cmdline packagegroup-core-sdk
> packagegroup-core-ssh-dropbear packagegroup-core-standalone-sdk-target
> packagegroup-core-tools-debug packagegroup-core-tools-profile
> packagegroup-core-tools-testapps packagegroup-fsl-optee-imx
> packagegroup-fsl-tools-audio packagegroup-fsl-tools-gpu-external
> packagegroup-tools-bluetooth pbzip2 pciutils perf pkgconfig procps
> psplash python python-dbus python-modules python-pandas python-pip
> python3 python3-dbus python3-misc python3-modules python3-pip
> python3-psutil python3-robotframework python3-six qt3d qt3d-dev
> qt3d-mkspecs qtbase qtbase-dev qtbase-mkspecs qtbase-plugins
> qtbase-tools libqt5charts5 libqt5charts-dev libqt5charts-mkspecs
> qtconnectivity-dev qtconnectivity-mkspecs qtdeclarative
> qtdeclarative-dev qtdeclarative-mkspecs qtgraphicaleffects
> qtgraphicaleffects-dev qtquickcontrols qtquickcontrols-dev
> qtquickcontrols-qmlplugins qtquickcontrols2 qtquickcontrols2-dev
> qtquickcontrols2-mkspecs libqt5svg5 libqt5svg-dev libqt5svg-mkspecs
> rpm rt-tests rtirq run-postinsts screen ssh-keys-server strace stress
> sysstat tar tmux trace-cmd ttf-bitstream-vera udev udev-automount
> unzip usbreset usbutils util-linux valgrind wget wireless-tools
> wpa-supplicant zip libz1 locale-base-en-us' returned 1:
> Added oe-repo repo from
> /home/user/test/os/build_fsl-image-validation-imx/tmp/work/imx8mmevk-poky-linux/custom-image-debug-imx8/1.0-r0/oe-rootfs-repo
> Last metadata expiration check: 0:00:00 ago on Mon 14 Jan 2019 04:06:18 PM 
> UTC.
> Error:
>  Problem: package connman-tools-1.35-r0.aarch64 requires connman, but
> none of the providers can be installed
>   - package packagegroup-core-tools-testapps-1.0-r2.imx8mmevk requires
> connman-tools, but none of the providers can be installed
>   - package networkmanager-1.10.6-r0.aarch64 conflicts with connman
> provided by connman-1.35-r0.aarch64
>   - conflicting requests
> (try to add '--allowerasing' to command line to replace conflicting
> packages or '--skip-broken' to skip uninstallable packages)
>
> ERROR: custom-image-debug-imx8-1.0-r0 do_rootfs: Function failed: do_rootfs
> ERROR: Logfile of failure stored in:
> /home/user/test/os/build_fsl-image-validation-imx/tmp/work/imx8mmevk-poky-linux/custom-image-debug-imx8/1.0-r0/temp/log.do_rootfs.56617
> ERROR: Task 
> (/home/user/test/os/sources/meta-custom-imx8/recipes-core/images/custom-image-debug-imx8.bb:do_rootfs)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 8016 tasks of which 7974 didn't need to
> be rerun and 1 failed.
>
> Many Thanks in advance,
> --
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org

Re: [meta-intel] D2800 Support w/NM10 chipset (Cedar Trail)

[Burton, Ross]

Unfortunately the PowerVR drivers for Cedar Trail are binary-only, so
you'll be stuck with compatible kernels.  If I were you I'd take the
drivers and kernel from Danny.

Ross

On Mon, 21 Jan 2019 at 10:52, Enrico Pelò  wrote:
>
> Hello to all,
>
> I need to build an image for support that old hardware D2800 Support w/NM10 
> chipset (Cedar Trail).
>
> I’ll need to install qt5 after the image test.
>
>
>
> I’ve tried to build with BITBAKE THUD’s meta-intel branch with 
> MACHINE=”intel-core2-32” (because the UEFI is not supported by the board)  in 
> my local.conf and the system starts but the video acceleration won’t work, 
> the screen resolution is 640x480
>
>
>
> I’ve configured
>
> LICENSE_FLAGS_WHITELIST="commercial"
>
> in my local.conf
>
>
>
> I’ve founded at this address 
> https://old.yoctoproject.org/downloads/bsps/danny13/cedar-trail-0 that the 
> local.conf must provide
>
> LICENSE_FLAGS_WHITELIST += "license_cdv-pvr-driver_1.0.3"
>
>
>
> But this does not fix the problem.
>
>
>
> I think the problem is that there aren’t the drivers for the PowerVR Graphics.
>
>
>
> Is there a workaround?
>
>
>
> Best regards
>
> Enrico
>
>
>
> --
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] D2800 Support w/NM10 chipset (Cedar Trail)

[Burton, Ross]

Not really.  If this is a commerical project then I'd recommend hiring
a consultant.  If its a hobbyist thing then you'll want to copy out
the driver and kernel recipes from the Danny release of meta-intel,
copy them into your own layer, change the configuration to use that
kernel, and see if they build.

To be honest the biggest problem might be finding a copy of the binary
drivers online...

Ross

On Mon, 21 Jan 2019 at 11:28, Enrico Pelò  wrote:
>
> Hi Ross,
> thank you for the fast response.
>
> I'm pretty new to the Yocto Project, is there some guides to achieve your 
> advice?
>
> Best regards
> Enrico
>
> On 21/01/2019, 12:09, "Burton, Ross"  wrote:
>
> Unfortunately the PowerVR drivers for Cedar Trail are binary-only, so
> you'll be stuck with compatible kernels.  If I were you I'd take the
> drivers and kernel from Danny.
>
> Ross
>
> On Mon, 21 Jan 2019 at 10:52, Enrico Pelò  
> wrote:
> >
> > Hello to all,
> >
> > I need to build an image for support that old hardware D2800 Support 
> w/NM10 chipset (Cedar Trail).
> >
> > I’ll need to install qt5 after the image test.
> >
> >
> >
> > I’ve tried to build with BITBAKE THUD’s meta-intel branch with 
> MACHINE=”intel-core2-32” (because the UEFI is not supported by the board)  in 
> my local.conf and the system starts but the video acceleration won’t work, 
> the screen resolution is 640x480
> >
> >
> >
> > I’ve configured
> >
> > LICENSE_FLAGS_WHITELIST="commercial"
> >
> > in my local.conf
> >
> >
> >
> > I’ve founded at this address 
> https://old.yoctoproject.org/downloads/bsps/danny13/cedar-trail-0 that the 
> local.conf must provide
> >
> > LICENSE_FLAGS_WHITELIST += "license_cdv-pvr-driver_1.0.3"
> >
> >
> >
> > But this does not fix the problem.
> >
> >
> >
> > I think the problem is that there aren’t the drivers for the PowerVR 
> Graphics.
> >
> >
> >
> > Is there a workaround?
> >
> >
> >
> > Best regards
> >
> > Enrico
> >
> >
> >
> > --
> > ___
> > meta-intel mailing list
> > meta-intel@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-intel
>
>
>
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] Atom E3826 storage that survives over reboot

[Burton, Ross]

EFI variables should work?

Ross

On Tue, 22 Jan 2019 at 08:20, Teemu K  wrote:
>
> Hi,
>
> Not exactly Yocto related, but was wondering if anyone have (new) ideas here.
>
> I have HW that has Congate TCA-3 board with Atom E3826 processor
> running Linux and there is need to relay information from Linux to
> bootloader for next warm boot. I only need few bytes. This information
> is used to determine if to boot secondary system on device or if to
> execute factory reset etc.
>
> Any idea where/how to store the information so it'd be (somewhat)
> easily accessible in bootloader(grub)? Congatec has their own CGOS
> system, but it's way too big for this job and doesn't work outside
> Linux. I'm not entirely sure if writing to RAM is good idea ie. can it
> lose it content on reboot?
>
> Of course generic approach would be nice, but Atom E3826 specific is
> also fine atm.
>
> -TeemuK
> --
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] ledmon: control hard disk led for RAID arrays

[Burton, Ross]

On Mon, 25 Mar 2019 at 05:24, Liwei Song  wrote:
> >> +EXTRA_OEMAKE = "CC='${CC}' LDFLAGS='${LDFLAGS}'"
> >
> > Are these needed, as they're exported.  If we need to pass LDFLAGS
> > like this, why not CFLAGS?
>
> This is used to fix an QA WARNING:
>
> WARNING: ledmon-0.90-git do_package_qa: QA Issue: No GNU_HASH in the ELF 
> binary 
> /project/tmp-glibc/work/corei7-64-wrs-linux/ledmon/0.90-git/packages-split/ledmon/usr/sbin/ledmon,
>  didn't pass LDFLAGS?

So you'll need to pass CFLAGS CPPFLAGS too then.

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

Re: [meta-intel] [PATCH 3/4] intel-graphics-compiler: add

[Burton, Ross]

On Fri, 5 Apr 2019 at 14:00, Anuj Mittal  wrote:
> +inherit cmake pythonnative

Assuming it's using the standard Python checkers in cmake then this
will probably work:

EXTRA_OECMAKE = "-DPYTHON_EXECUTABLE=${HOSTTOOLS_DIR}/python3"

(or maybe python2 if it needs Py2 and can't handle py3)

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