[linux-yocto] [yocto-kernel-cache] [PATCH] SSP Audio configuration for Leaf Hill BSP

Hi, This is to enable Intel SoC SST codecs supported by Leaf Hill BSP. The driver required is snd_soc_intel_sst. This feature is Intel SSP Audio. Currently it is Leaf Hill specific and it can't co-exist together with Intel HD-Audio feature. We need to disable snd_hda_intel when we enable Intel

[linux-yocto] [yocto-kernel-cache] [PATCH] bsp: leafhill: snd_ssp_intel: add ssp audio configuration fragment

Enable snd_soc_intel_sst and its codecs supported by Leaf Hill BSP. Intel SSP Audio feature can't co-exist together with Intel HD-Audio feature. We need to disable snd_hda_intel and its supported codecs when SSP audio is enabled. Signed-off-by: Rebecca Chang Swee Fun

Re: [yocto] Compilation error

Smells like you didn't include a file. man 2 close says: #include Frederick From: yocto-boun...@yoctoproject.org on behalf of Rudolf Streif Sent: Monday, September 12, 2016 6:53 PM To: Vijayakumar

Re: [linux-yocto] [PATCH 0/5] Backport on linux-yocto-4.4 bxt-rebase branch

On Mon, Sep 12, 2016 at 6:25 PM, Nilesh Bacchewar < nilesh.bacche...@intel.com> wrote: > Backport Enable Pooled EU support patches to linux-yocto-4.4. These > patches are > for BXT-M standard SKUs. Patches have been approved and available on > upstream > kernel. Rebased on bxt-rebase branch. >

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: exclude IMAGEDATESTAMP from signatures of do_image_rpi_sdimg

Hi Andreas/Khem, On 13 September 2016 at 09:04, Andreas Müller wrote: > On Wed, Aug 17, 2016 at 6:58 AM, Khem Raj wrote: >> Fixes taskhash mismatch e.g. >> >> ERROR: core-image-minimal-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch >>

Re: [yocto] [meta-raspberrypi][PATCH 1/2] sdcard_image-rpi.bbclass: remove stamp file

Hi Andreas, On 13 September 2016 at 10:19, Andreas Müller wrote: > stamp files are not of much use and this patch fixes: > ERROR: kde-base-image-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch > 3fad6675b6fcc6b048099609adf21967 versus f0665d2ea6d2db2359c456c60a33e52e

[yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: remove redundant IMAGEDATESTAMP

The IMAGE_NAME variable already contains the date and time so it is redundant to also include the date again with IMAGEDATESTAMP when writing to image-version-info in the boot partition. Signed-off-by: Jonathan Liu --- classes/sdcard_image-rpi.bbclass | 8 ++-- 1 file

Re: [yocto] Compilation error

What recipe? Ideally you want to fix the code and add the function declaration. Kind regards, Rudolf J Streif On Sep 12, 2016 6:26 PM, "Vijayakumar Badiger" wrote: > Hello All, > > I am getting an compilation error like below. Can you pls let me know how > to fix this

[yocto] Modify fetch URL in BBappend file

Hello All We are including the meta-ivi layer in our custom distribution. There is a package 'dlt-daemon' whose fetch URL got modified upstream in the recipe file due to some corruption in the repositories. I want to modify this URL in the corresponding bbappend file in my custom BSP layer. I

[yocto] Compilation error

Hello All, I am getting an compilation error like below. Can you pls let me know how to fix this one. Thanks in advance. error: implicit declaration of function 'close' [-Werror=implicit-function-declaration] | close(fd); Cheers, Vijay --

[yocto] [meta-raspberrypi][PATCH 2/2] sdcard_image-rpi.bbclass: avoid corrupted images with latest oe-core

oe-core's commit d54339d4b1a7e884de636f6325ca60409ebd95ff creates image in IMGDEPLOYDIR and copies through sstate to DEPLOY_DIR_IMAGE. That causes DEPLOY_DIR_IMAGE not valid when calling IMAGE_CMD. Therefore use IMGDEPLOYDIR for sdcard creation too. Signed-off-by: Andreas Müller

[yocto] [meta-raspberrypi][PATCH 1/2] sdcard_image-rpi.bbclass: remove stamp file

stamp files are not of much use and this patch fixes: ERROR: kde-base-image-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch 3fad6675b6fcc6b048099609adf21967 versus f0665d2ea6d2db2359c456c60a33e52e for

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: exclude IMAGEDATESTAMP from signatures of do_image_rpi_sdimg

On Wed, Aug 17, 2016 at 6:58 AM, Khem Raj wrote: > Fixes taskhash mismatch e.g. > > ERROR: core-image-minimal-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch > 78b2e0830a66052318e5e7eba193 versus 4b9bbe5dba1b48cf5cb5ad365d991de9 for >

[linux-yocto] [PATCH 3/5] drm/i915/bxt: Export pooled eu info to userspace

From: "arun.siluv...@linux.intel.com" Backport: - commit 37f501afed23fa1126017255495d5be5e97c9d6d upstream. - backport fix. Pooled EU is a bxt only feature and kernel changes are already merged. This feature is not yet exposed to userspace as the

[linux-yocto] [PATCH 4/5] drm/i915/bxt: update list of PCIIDs

From: Imre Deak Backport: commit 985dd4360fdf2533fe48a33a4a2094f2e4718dc0 upstream. Add PCIIDs for new versions of the SOC, based on BSpec. Also add the name of the versions as code comment where this is available. The new versions don't have any changes visible to the

[linux-yocto] [PATCH 1/5] drm/i915:bxt: Enable Pooled EU support

From: "arun.siluv...@linux.intel.com" Backport: commit 33e141ed1cf74cd8ef26e5f175e43e378157a649 upstream. This mode allows to assign EUs to pools which can process work collectively. The command to enable this mode should be issued as part of context

[linux-yocto] [PATCH 2/5] drm/i915/bxt: Add WaEnablePooledEuFor2x6

From: "arun.siluv...@linux.intel.com" Backport: commit e015dd69b2cf8d639308ad1cb4cd204a24e918fe upstream. Pooled EU is enabled by default for BXT but for fused down 2x6 parts it is advised to turn it off. But there is another HW issue in these parts (fused down

[linux-yocto] [PATCH 0/5] Backport on linux-yocto-4.4 bxt-rebase branch

Backport Enable Pooled EU support patches to linux-yocto-4.4. These patches are for BXT-M standard SKUs. Patches have been approved and available on upstream kernel. Rebased on bxt-rebase branch. Imre Deak (1): drm/i915/bxt: update list of PCIIDs arun.siluv...@linux.intel.com (4):

Re: [yocto] Striping cross-compiled paths

On Mon, Sep 12, 2016 at 08:16:02PM +0100, Burton, Ross wrote: > If those paths come from __FILE__ and so on, then currently no. It would > be great if GCC could do this, but currently it can not. __FILE__ contains whatever was passed to gcc, so if you ask it to do: gcc file.c then __FILE__

Re: [yocto] Striping cross-compiled paths

Thanks, I just found this post was addressed already -> https://lists.yoctoproject.org/pipermail/poky/2015-August/010197.html On Mon, Sep 12, 2016 at 1:16 PM, Burton, Ross wrote: > > On 12 September 2016 at 19:22, Matthew Stanger < > matthew_stan...@trimble.com> wrote: >

Re: [yocto] Striping cross-compiled paths

On 12 September 2016 at 19:22, Matthew Stanger wrote: > I'm using Yocto 1.7.1 I'd like built programs to have the build path > striped down. The goal is if I'm looking at some programs log after cross > compiling I want this: > > src/program.c:388 > > where I

[yocto] Striping cross-compiled paths

I'm using Yocto 1.7.1 I'd like built programs to have the build path striped down. The goal is if I'm looking at some programs log after cross compiling I want this: src/program.c:388 where I currently get this:

Re: [yocto] Naive Questsions about 3rd Party Kernel Module

I was able to resovle my problem (with a bit of help from Google and Stack Overflow) by including a stub version of __stack_check_fail() in my recepie. It appears that the shared object libarary was not needed after all, and was just a red herring in my invesgagation. Thank you for your

Re: [yocto] Naive Questsions about 3rd Party Kernel Module

On Mon, Sep 12, 2016 at 01:41:24PM -0300, Daniel. wrote: > If you don't make your driver GPL you can't access GPL symbols. This > *may* be the reason behind the "Unknown symbols" > Regards, Well at least for __stack_chk_fail the kernel has: #ifdef CONFIG_CC_STACKPROTECTOR /* * Called when

Re: [yocto] Naive Questsions about 3rd Party Kernel Module

Ronald, If you don't make your driver GPL you can't access GPL symbols. This *may* be the reason behind the "Unknown symbols" Regards, 2016-09-12 13:02 GMT-03:00 Lennart Sorensen : > On Fri, Sep 09, 2016 at 04:02:21PM -0600, Ronald Oakes wrote: >> Following up as

Re: [yocto] Naive Questsions about 3rd Party Kernel Module

On Fri, Sep 09, 2016 at 04:02:21PM -0600, Ronald Oakes wrote: > Following up as I've done more investigation and debugging this afternoon: > > I've been able to resolve my problem with the missing symbolic link to > .so by explicitly including a runtime dependency > (RDEPENDS_${PN}) to the -dev

Re: [yocto] Subjects for YP Developer Day at ELCE

On 12 September 2016 at 15:48, William Mills wrote: > 5) Can Yocto [cross-]build snaps or flatpaks? > Just because it's interesting, note that the standard freedesktop.org flatpak runtime is in fact bootstrapped through a custom OE distro. Ross --

Re: [yocto] Subjects for YP Developer Day at ELCE

On 09/09/2016 11:51 AM, Jeff Osier-Mixon wrote: Hi all - we are in the planning stages for DevDay at ELCE right now, particularly the advanced track. This track changes every session, usually to cover the things we are working on hardest - for example, in San Diego we covered CROPS, devtool,

Re: [yocto] Cortex-M4 build support

On 9/12/16 12:07 AM, Zhenhua Luo wrote: > Hi Mark, > > Thanks a lot for your comments. > > Is there plan to support non-MMU targets in Yocto? > Not that I am aware of. --Mark > Best Regards, > > Zhenhua > >> -Original Message- >> From: Mark Hatle

[yocto] [yocto-autobuilder][PATCH] checkvnc: use netstat to detect running vncserver

Using `pidof Xvnc` isn't sufficient because on debian-based distros the vncserver script will start Xtightvnc. Instead switch back to using netstat for the VNC tcp socket to detect a running vncserver. [YOCTO #10257] Signed-off-by: Joshua Lock --- bin/checkvnc | 2 +-

Re: [yocto] [Yocot] : undefined reference to `__init_array_start' error.

Hi Ross, Thanks for your reply,it's working for me ..:) Regards Bharath On Fri, Sep 9, 2016 at 6:46 AM, Burton, Ross wrote: > This is because your distro has enabled the security options, but > native-frameworks has bad link lines that work without security flags more >

Re: [yocto] [meta-swupd][PATCH] swupdimage.bbclass: ensure that do_rootfs gets executed

On Mon, 2016-09-12 at 09:09 +0200, Patrick Ohly wrote: > OE-core commit 6d969bacc718e changed do_rootfs so that it creates > IMGDEPLOYDIR. That change broke the creation of additional swupd > images, because setting do_rootfs to empty caused the entire task to > be skipped, including the

[yocto] [meta-swupd][PATCH] swupdimage.bbclass: ensure that do_rootfs gets executed

OE-core commit 6d969bacc718e changed do_rootfs so that it creates IMGDEPLOYDIR. That change broke the creation of additional swupd images, because setting do_rootfs to empty caused the entire task to be skipped, including the evaluation of the 'cleandirs' task attribute. It remains to be seen

[yocto] : error: '__uint128_t' does not name a type

Hi All, I am trying to build one recipes on Yocto2.0 based environment. However I am seeing following error.I wonder if this is a known problem. It says error: '__uint128_t' does not name a type

Re: [yocto] Cortex-M4 build support

Hi Mark, Thanks a lot for your comments. Is there plan to support non-MMU targets in Yocto? Best Regards, Zhenhua > -Original Message- > From: Mark Hatle [mailto:mark.ha...@windriver.com] > Sent: Friday, September 09, 2016 10:37 PM > To: Zhenhua Luo ;

Re: [yocto] [meta-swupd][PATCH] swupdimage.bbclass: ensure that do_rootfs gets executed

Hello Joshua! Please also apply to the pre-sstate branch. There's a slight merge conflict (previous line differs), but that's easy to resolve, so I am not sending that as a separate patch. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am

Re: [yocto] Problem with exporting variable in bbappend file

A couple of things: 1) If you're not already, use bitbake -e and not just bitbake -e 2) I'd also recommend not piping through grep - pipe through "less" instead and search for the variable with / - this means you can see the history of how the variable's value got set. Cheers, Paul On Mon,