[linux-yocto] [PATCH v3 1/1] drm/i915: Fix v4.4.20 -> v4.4.22 i915 merge.

Some patches did not merge cleanly in previous merge, causing build failures. The i915 changes between 94e5bb30ea and 1fd9c1008d were reverted and the patches were reapplied as follows, then the results were squashed. Commit a554bd7ccf "drm/i915: Fix hpd live status bits for g4x" was already

Re: [linux-yocto] [PATCH v2 1/1] drm/i915: Fix v4.4.20 -> v4.4.22 i915 merge.

DO NOT MERGE. Apologies, but my commit message is actually incorrect here, this actually fixes two patches. It seems that despite applying cleanly, one of the patches did somehow not get merged correctly. I will send a v3 in a few minutes. Thanks, Cal On 10/14/2016 03:17 PM, California

[linux-yocto] [PATCH v2 1/1] drm/i915: Fix v4.4.20 -> v4.4.22 i915 merge.

Portions of commit e153f52df9 "drm/i915: Check VBT for port presence in addition to the strap on VLV/CHV" were missed in the merge commit, causing build errors. This patch fixes the issues by reverting the i915 changes in the merge, reapplying the patches and fixing conflicts where they occur,

Re: [yocto] [meta-mingw] Patch needed to let linker find lto plugin

Thanks. I will re-run some basic tests again and send the patch by Mark Hatle (applied to meta-mingw/krogoth) to the mailing list. > -Original Message- > From: winfried.do...@xmsnet.nl [mailto:winfried.do...@xmsnet.nl] > Sent: Friday, October 14, 2016 11:35 AM > To: Bystricky, Juro

Re: [linux-yocto] [PATCH 1/1] drm/i915: Fix v4.4.20 -> v4.4.22 i915 merge.

On Fri, Oct 14, 2016 at 02:14:02PM -0700, California Sullivan wrote: > The addition of a new function and some return types was missed in the > original merge, causing build errors. > If it were me, I would want to have details on exactly which patches had conflicts, since it appears you went

Re: [linux-yocto] [PATCH 1/1] drm/i915: Fix v4.4.20 -> v4.4.22 i915 merge.

On 10/14/2016 02:19 PM, Ernst, Eric wrote: On Fri, Oct 14, 2016 at 02:14:02PM -0700, California Sullivan wrote: The addition of a new function and some return types was missed in the original merge, causing build errors. If it were me, I would want to have details on exactly which patches

[linux-yocto] [PATCH 1/1] drm/i915: Fix v4.4.20 -> v4.4.22 i915 merge.

The addition of a new function and some return types was missed in the original merge, causing build errors. Signed-off-by: California Sullivan --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_bios.c| 39

[linux-yocto] [PATCH 0/1] Fix i915 merge

Hi Eric, The conversation with you, Ilkka, and Fei seems to point towards just fixing the few merge conflicts we get with stable, so that's what I have here. I have built and boot tested this patch but I don't know if I have the process correct. This is a squashed version of reverting the i915

Re: [yocto] [meta-mingw] Patch needed to let linker find lto plugin

Hi Juro, My Yocto environment is for the Congatec QMX6 SoM that is built around a quadcore i.MX6. I use the Yocto layers from the Congatec repository (https://git.congatec.com/public), which includes the meta-fsl-arm and meta-fsl-arm-extra layers. My bblayers.conf is: BBLAYERS = " \

[yocto] [meta-mingw] Patch needed to let linker find lto plugin

Recently the meta-mingw layer was updated to krogoth by Juro Bystricky. Thanks ! However when I build it as-is, the linker fails because it can't load the lto plugin. After applying commit a06e473590207f72b11d273a09de2c8a889c381e from meta-mingw-contrib (by Mark Hatle), the error disappeared.

Re: [yocto] [meta-mingw] Patch needed to let linker find lto plugin

Could you please elaborate on what do you mean by "built it as-is". I tested the meta layer with some cases I considered typical or most common. (I think I enumerated them in my original message). Apparently I missed one. Thanks Juro > -Original Message- > From: Winfried

Re: [yocto] Two pythons

On Fri, Oct 14, 2016 at 8:54 AM, Burton, Ross wrote: > On 12 October 2016 at 18:58, Michael Callahan > wrote: > >> I just moved my project from Fido to Krogoth and now I have two >> pythons (2.7 and 3). This bumps the size of my image by

[linux-yocto] [PATCH] bsp/axxiaarm[64]: Update fragments and enable RAPIDIO

Signed-off-by: Daniel Dragomir --- bsp/axxiaarm/axxiaarm.cfg | 2 ++ bsp/axxiaarm64/axxiaarm64.cfg | 8 bsp/axxiaarm64/axxiaarm64.scc | 1 + bsp/axxiaarm64/rapidio.cfg| 27 +++ bsp/axxiaarm64/rapidio.scc| 4 5

[linux-yocto] [PATCH] Intel Axxia updates to yocto-kernel-cache yocto-4.1

Hello Bruce! Please apply this path on the 'yocto-4.1' branch from git.yoctoproject.org/yocto-kernel-cache This patch enable RAPIDIO driver for axxiaarm64 bsp and also make some option updates in both axxia bsps. Thank you, Daniel Dragomir (1): bsp/axxiaarm[64]: Update fragments and enable

Re: [yocto] Two pythons

On 12 October 2016 at 18:58, Michael Callahan wrote: > I just moved my project from Fido to Krogoth and now I have two > pythons (2.7 and 3). This bumps the size of my image by approximately > 25%. What would be the most reasonable way to get back to just one >

[yocto] Yocto recipe license

Hello, it seems that license.manifest file describes application/lib/etc. source code license, but what about Yocto recipe license itself ? So what is the license of a Yocto recipe ? How to know it ? If a Yocto recipe is GPL2, and we extend (*.bbappend) this recipe, does contamination effect

[yocto] [meta-raspberrypi] build rpi-test-image for raspberrypi3

Hello, I am trying to build the rpi-test-image for a raspberrypi3 using the Poky and raspberrypi master branches. Below are the layers I include in my 'bblayers.conf': ${BSPDIR}/master/poky/meta \ ${BSPDIR}/master/poky/meta-poky \ ${BSPDIR}/master/poky/meta-yocto-bsp \

[yocto] [meta-raspberrypi] Master doesn't seem to be building right...

It's boggling on the sd card image build. Attached is the console output from the build (Don't need the log, this one's clear from the build fail output.) and a dump of the directory structures in tmp/deploy/images/raspberrypi2 from my setup. It's choking on trying to put the overlays onto

[yocto] Two pythons

I just moved my project from Fido to Krogoth and now I have two pythons (2.7 and 3). This bumps the size of my image by approximately 25%. What would be the most reasonable way to get back to just one python? Ideally I'd like a magical setting to get rid of python3 because there is no custom

Re: [yocto] Big endian ARM machine with NEON wanted

On Fri, Oct 14, 2016 at 07:41:13AM +0200, Mike Looijmans wrote: > On 13-10-16 19:20, Andreas Müller wrote: > > > >Does anybody know a big endian and common machine supporting NEON? I > >would need one for testing my port of portaudio. > > > Most ARM systems can run in both big-endian and

Re: [yocto] failed to copy the final ***rootfs.rpi-sdimg image file

Great! Thanks! Sent from my WIKO RAINBOW LITE 4GLe 14 oct. 2016 14:41, Andrei Gherzan a écrit : > > On Sat, Oct 01, 2016 at 01:58:49PM +, Karim ATIKI wrote: > > hi, > > > > > > I'm building a custom core-image-x11 for my raspberrypi3 board, with poky > > krogoth. >

Re: [yocto] [meta-raspberrypi] taskhash mismatch

On Fri, Oct 14, 2016 at 08:50:05AM -0400, Trevor Woerner wrote: > On Fri, Oct 14, 2016 at 5:25 AM, Andrei Gherzan wrote: > > I know I'm kinda late to the party but just wanted to say that this was > > fixed in master. Cheers! > > Excellent. I just tried 3 builds in a row and

Re: [yocto] [meta-raspberrypi] taskhash mismatch

On Fri, Oct 14, 2016 at 5:25 AM, Andrei Gherzan wrote: > I know I'm kinda late to the party but just wanted to say that this was > fixed in master. Cheers! Excellent. I just tried 3 builds in a row and they all succeeded! Thanks for the update. --

Re: [yocto] failed to copy the final ***rootfs.rpi-sdimg image file

On Sat, Oct 01, 2016 at 01:58:49PM +, Karim ATIKI wrote: > hi, > > > I'm building a custom core-image-x11 for my raspberrypi3 board, with poky > krogoth. > > In the very last steps: > > > ERROR: core-image-x11-1.0-r0 do_image_rpi_sdimg: Function failed: > do_image_rpi_sdimg (log file is

Re: [yocto] [meta-raspberrypi][PATCH] bluez5: correctly append brcm43438 service

On Tue, Oct 04, 2016 at 12:51:34PM +0300, Samuli Piippo wrote: > Cannot use += operator together with machine override. > > Signed-off-by: Samuli Piippo > --- > recipes-connectivity/bluez5/bluez5_%.bbappend | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff

Re: [yocto] [yocto-autobuilder][PATCH] PublishArtifacts.py: deal only with built toolchains, cp also md5 and manifests

Hi, On 2016-10-14 04:27, Joshua Lock wrote: This is a reasonable goal, but something I'd rather see addressed in the proposed PublishArtifacts rewrite. As we're trying to release morty right now I'd like to avoid changes to the AB behaviour until after the release. I'm absolutely happy with

[yocto] Fwd: Failed to build image, output error "ERROR: Worker process (11579) exited unexpectedly (-9), shutting down..."

Hi ALL: I am an software engineer in Askey. I have one question about building the apq-8053 device image. The main question is that I can not build well. Below is the error messages which show unexpected shutdown. I have studied from the web site and google and found the following links shows

Re: [yocto] [yocto-autobuilder][PATCH] PublishArtifacts.py: deal only with built toolchains, cp also md5 and manifests

On Thu, 2016-10-13 at 17:38 -0500, gm...@reliableembeddedsystems.com wrote: > Hi, > > On 2016-10-13 16:29, Lock, Joshua G wrote: > > > > Can you help me understand why you needed to create this patch? > > > > We've run into some issues recently where toolchains we expected to > > be > > built

Re: [yocto] [meta-raspberrypi] taskhash mismatch

On Sun, Oct 02, 2016 at 10:34:22AM -0400, Trevor Woerner wrote: > Hi, > > For the last week or so my raspberry pi builds have been failing with: > > ERROR: core-image-minimal-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch > 2920e557ac3a011d5679a52590cb664d versus a47bfc12fdfa29c58fe72cf8e0a28e91

Re: [yocto] Migration info - runqemu

On 10/14/2016 04:35 PM, Lock, Joshua G wrote: On Fri, 2016-10-14 at 10:12 +0800, Robert Yang wrote: Hi Paul and Scott, Here it is, and please feel free to comment, most of them are from qemuboot.bbclass: The new runqemu is a python script, it requires a -.qemuboot.conf to boot the bsp, the

Re: [yocto] Migration info - runqemu

On Fri, 2016-10-14 at 10:12 +0800, Robert Yang wrote: > Hi Paul and Scott, > > Here it is, and please feel free to comment, most of them are from > qemuboot.bbclass: > > The new runqemu is a python script, it requires a > -.qemuboot.conf to boot the bsp, the > qemuboot.conf > is generated by

Re: [yocto] add dejavu-fonts to image

Ok, i will test this week end and let you know ! Otherwise, if you build qt5.7 perhaps you can have the same issue like me with sdk, see here for more details : https://github.com/graugans/meta-udoo/issues/20 regards Le 13/10/2016 à 18:12, Michel D'HOOGE a écrit : After solving all the QA

Re: [yocto] Migration info - runqemu

Hi Robert, On 2016-10-14 05:12, Robert Yang wrote: QB_SYSTEM_NAME: qemu name, e.g., "qemu-system-i386" QB_OPT_APPEND: options to append to qemu, e.g., "-show-cursor" ... Could you also please mention which of those values are obligatory and what are the default values in case they are not

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: Remove redundant RPI_KERNEL_VERSION

On Thu, Oct 06, 2016 at 05:55:05PM +0200, Andreas Müller wrote: > On Thu, Oct 6, 2016 at 2:20 PM, Jonathan Liu wrote: > > The value of the RPI_KERNEL_VERSION can change between None and the > > kernel version which can result in taskhash mismatch errors while > > building

Re: [yocto] Yocto recipe license

On 14 October 2016 at 06:23, Contrib Open Source < contrib.open.sou...@gmail.com> wrote: > Here "metadata" stands for "oe-core recipe", right ? > "metadata" includes all the recipes and classes in oe-core. > What if we extend (*.bbappend) a GPLv2 recipe: is it "contaminated" or not > ? >

Re: [yocto] [meta-raspberrypi][PATCH V2 1/2] linux-raspberrypi: Add recipe for 4.8 release

On Thu, Oct 13, 2016 at 01:15:31AM -0700, Khem Raj wrote: > Signed-off-by: Khem Raj > --- > recipes-kernel/linux/linux-raspberrypi_4.8.bb | 8 > 1 file changed, 8 insertions(+) > create mode 100644 recipes-kernel/linux/linux-raspberrypi_4.8.bb > > diff --git

Re: [yocto] [meta-raspberrypi][PATCH 1/4] linux-raspberrypi_4.4: Upgrade to 4.4.23

On Thu, Oct 06, 2016 at 07:09:03PM -0700, Khem Raj wrote: > Drop upstreamed patch > > Signed-off-by: Khem Raj > --- > .../0002-vc4-ioctl-rendering-allow.patch | 29 > -- > recipes-kernel/linux/linux-raspberrypi_4.4.bb | 5 ++-- > 2 files

Re: [yocto] Big endian ARM machine with NEON wanted

On Fri, Oct 14, 2016 at 7:41 AM, Mike Looijmans wrote: > On 13-10-16 19:20, Andreas Müller wrote: >> >> >> Does anybody know a big endian and common machine supporting NEON? I >> would need one for testing my port of portaudio. > > > > Most ARM systems can run in both

Re: [yocto] Big endian ARM machine with NEON wanted

On 13-10-16 19:20, Andreas Müller wrote: Does anybody know a big endian and common machine supporting NEON? I would need one for testing my port of portaudio. Most ARM systems can run in both big-endian and little-endian modes. Somewhere early during boot this choice is being made.