From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 744F2E00CC0; Wed, 18 Oct 2017 16:04:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [74.125.83.49 listed in list.dnswl.org] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (marlon.smith10[at]gmail.com) * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com [74.125.83.49]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 0BAE6E00C96 for ; Wed, 18 Oct 2017 16:04:03 -0700 (PDT) Received: by mail-pg0-f49.google.com with SMTP id r25so5490646pgn.4 for ; Wed, 18 Oct 2017 16:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:date:in-reply-to:references:mime-version; bh=L/ObC9b7wvNr6auy5rKtAqfHlW7QQtnLyXBkPQ2CehY=; b=t4Aj8nTTPsY+FGg+R3YDGRTuGucaCLQXsJKuZZdkkD6qNlmGxFU0G2FBzkyroLxGva j4LhIi/rM/PNhpSM6o7GtnsqHarDTISyeYTuOYJEVwStRSs1DfYGmORNwjtlJ/DeesUl JxJMmBUYzvvrCcxvaO7WCb9nGD04Qmb4AXdSJ9Ik9cciZ/oRNS9H78yOysI0LiQbGy9F Mkvv/4UN8gP5GgDypWgIlPYLHopPIJQlSKCZNF2H9R9mZtI62ozcuzPaoY2HMdlT5R0k VxXP1rAyb1hqaGvWpWQL3pUESNWwEIs4pbmzAsGvmzuh1HOW7WIxY5bPNCRsTOKXyD0E opvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version; bh=L/ObC9b7wvNr6auy5rKtAqfHlW7QQtnLyXBkPQ2CehY=; b=acoA+apqlg+L0rhvLHwP7qc8fV882+3F18osb3oUIHBwsbmGn4UcgrDxsSl/UgYXAk CIqsFiG+laYctZ79dvV0ZxRwicpDKyiL/r29fTOvwMMVT82ztdJec4MCBSBGEFt8H/Kf xMIl8nSUowvraS70ruGtpIjZg/z+eWZXnAn7HfqFYC0wB+LTJu3V4zR/upBtnaSrqXJf FsnqksH52KUrkzR5qjNIrUiRdi/gzxqYeocy8oW+ZBJPqXKPkQRY7Gk4qzzPJfx62HSM 2abpnvivmgjWj2hv2vz4AE6P3c69gYb/DJjW3TYdbUY6qpIvWkj0BjXWPt8grk/Wcirm yegA== X-Gm-Message-State: AMCzsaWKNbHJawdzBMomtfOEaTUEtazn+/wHNUl9Cgw71KhxpPaQ8NIh Q158xXhmHKV0y0cLUK1Euh4kBQ== X-Google-Smtp-Source: ABhQp+Rmc5CP+j7ayfgAdF0kTzid1x5g7KCixwb25aJARzc218+/SUEapiRIJxP1IHFvDsXS75bN8Q== X-Received: by 10.98.218.13 with SMTP id c13mr13830832pfh.342.1508367843537; Wed, 18 Oct 2017 16:04:03 -0700 (PDT) Received: from [10.2.0.10] (S0106a84e3f53ec33.gv.shawcable.net. [184.66.238.184]) by smtp.gmail.com with ESMTPSA id u77sm21442871pfd.168.2017.10.18.16.04.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Oct 2017 16:04:02 -0700 (PDT) Message-ID: <1508367841.4636.35.camel@gmail.com> From: Marlon Smith To: Darcy Watkins , "yocto@yoctoproject.org" Date: Wed, 18 Oct 2017 16:04:01 -0700 In-Reply-To: References: <1508364829.4636.30.camel@gmail.com> X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 Subject: Re: Building kernel backports for ARM with Yocto X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 23:04:05 -0000 Content-Type: multipart/alternative; boundary="=-tNSuzgkwgZqoqBIoNQYO" --=-tNSuzgkwgZqoqBIoNQYO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Darcy, thanks for the detailed reply! Do you remember how you were able to get it to compile in the first place?  I end up with this error: ./kconf/conf: 1: ./kconf/conf: Syntax error: word unexpected (expecting ")") ..because backports needs to compile conf for x86_64, but instead compiles it for ARM.  Once that step is done, it needs to compile the rest of the project for ARM, but this error stops it. I think I could work around the sysroot arm-wrestle because of the way our project is built, but haven't made it to that point yet. Here's the bb file I'm using: --------------------------- include backports.inc SRCBRANCH = "linux-4.2.y" LOCALVERSION = "v4.2.6-1-0-g90118c7" SRCREV = "90118c7656bb55243620c9dc9cc3f12582b1807f" DEPENDS += "linux-myproject"do_configure_prepend() { export CROSS_COMPILE=${TARGET_PREFIX} export ARCH=${TARGET_ARCH} export KLIB_BUILD=${STAGING_KERNEL_DIR} export KLIB=${STAGING_DIR_TARGET} make } ----------------------------------- On Wed, 2017-10-18 at 22:53 +0000, Darcy Watkins wrote: > I tried building backports under Yocto a few years back using Yocto > daisy branch with kernel 3.4 for x86 and kernel 3.12 for ARM.  After > a fair amount of pain I was able to get it to sort of work.  The > problem was mainly a sysroot arm-wrestle between kernel and backports > because they both generate the same kernel module packages.  It was a > last-one-wins arm-wrestle.  It sort of worked OK with daisy branch, > but newer yocto versions have stricter management of sysroots and > staging areas. >   > I think what we need is some sort of virtual provider or alternatives > scheme to make this work properly. >   > You can also run into problems related to exports to other out-of- > tree modules but IIRC, it would only affect an out-of-tree module > with an incompatible license. >   > I was able to run a few circa kernel 3.18 backports experimentally on > a kernel 3.4 and a kernel 3.12.  Eventually we just upgraded the > kernel.  Another project I know of used backports to update their > kernel source and then created a recipe to build kernel from that > source. >   > The notes/questions I had in the end were: >   > was building backports as out-of-tree kernel modules > was concerned that this wouldn’t provide updated kernel staging > source, particularly with respect to any updated includes > wasn’t sure what would be propagated into the sysroot > should consider the backports use case that patches the kernel source > and then perhaps use this to generate patchset to be added to kernel > recipe (bbappend) > otherwise need to ensure proper handling of sysroot, staging, (as > well as a notion of providers and/or alternatives like I mentioned > earlier) >   > I haven’t touched this in years, but perhaps it may help a bit. >   > I think your best bet for short term is to use it to patch the kernel > and then capture the changes as a patchset to add to a kernel recipe. >   >   >   > Regards, >   > Darcy >   > Darcy Watkins ::  Senior Staff Engineer, Firmware >   > SIERRA WIRELESS > Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604 > 231 1100 > 13811 Wireless Way  :: Richmond, BC Canada V6V 3A4 > [P2] > dwatkins@sierrawireless.com :: www.sierrawireless.com >   > From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproje > ct.org] On Behalf Of Marlon Smith > Sent: October-18-17 3:14 PM > To: yocto@yoctoproject.org > Subject: [yocto] Building kernel backports for ARM with Yocto >   > Hi everyone, >   > I'm trying to build the Linux backports project to get updated wifi > drivers on an older kernel.  The problem is that when building > backports, it first builds several tools that need to be run natively > before cross-compiling the rest of the project. >   > I know how to write a bitbake recipe to compile natively, and how to > write one to build for the target, but I can't figure out how to > combine the two.  The backports project has steps for LTIB: >   >  %Build >  export PATH=$UNSPOOF_PATH >   >  make menuconfig prefix=%{_prefix} \ >    CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \ >    ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \ >    KLIB_BUILD=${TOP}/rpm/BUILD/linux >   >  export PATH=$SPOOF_PATH >   >  make prefix=%{_prefix} \ >    CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX} \ >    ARCH=$LINTARCH KLIB=${TOP}/rootfs/lib/modules/%{kversion} \ >    KLIB_BUILD=${TOP}/rpm/BUILD/linux >   > I believe what I need is an equivalent to the line export > PATH=$UNSPOOF_PATH but I can't find anything in the Yocto > documentation or mailing lists that would be equivalent to that. >   > Any help would be much appreciated! >   > Thanks >   > Marlon --=-tNSuzgkwgZqoqBIoNQYO Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Darcy, thanks for the detailed reply!
<= br>
Do you remember how you were able to get it to compile in the= first place?  I end up with this error:

./kc= onf/conf: 1: ./kconf/conf: Syntax error: word unexpected (expecting ")")

..because backports needs to compile conf for x86_64= , but instead compiles it for ARM.  Once that step is done, it needs t= o compile the rest of the project for ARM, but this error stops it.

I think I could work around the sysroot arm-wrestle becau= se of the way our project is built, but haven't made it to that point yet.<= /div>

Here's the bb file I'm using:

=
---------------------------

include backports= .inc

SRCBRANCH =3D "linux-4.2.y"
LOCALVE= RSION =3D "v4.2.6-1-0-g90118c7"
SRCREV =3D "90118c7656bb55243620c= 9dc9cc3f12582b1807f"

DEPENDS +=3D "linux-myproject= "

do_configure_prepend() {
export CROSS_COMPIL= E=3D${TARGET_PREFIX}
export ARCH=3D${TARGET_ARCH}
export KLIB_BUILD=3D${STA= GING_KERNEL_DIR}
export KLIB=3D${STAGING_DIR_TARGET}
make
}

-----------------------------------

On Wed, 2017-10-18 at 22:53 +0000, Darcy Watkins wrote:

I tried b= uilding backports under Yocto a few years back using Yocto daisy branch wit= h kernel 3.4 for x86 and kernel 3.12 for ARM.  After a fair amount of = pain I was able to get it to sort of work.  The problem was mainly a sysroot arm-wrestle between kernel and backports = because they both generate the same kernel module packages.  It was a = last-one-wins arm-wrestle.  It sort of worked OK with daisy branch, bu= t newer yocto versions have stricter management of sysroots and staging areas.

&nbs= p;

I think w= hat we need is some sort of virtual provider or alternatives scheme to make= this work properly.

&nbs= p;

You can a= lso run into problems related to exports to other out-of-tree modules but I= IRC, it would only affect an out-of-tree module with an incompatible licens= e.

&nbs= p;

I was abl= e to run a few circa kernel 3.18 backports experimentally on a kernel 3.4 a= nd a kernel 3.12.  Eventually we just upgraded the kernel.  Anoth= er project I know of used backports to update their kernel source and then created a recipe to build kernel from that so= urce.

&nbs= p;

The notes= /questions I had in the end were:

&nbs= p;

  • was building backports as out-of= -tree kernel modules
  • was concerned that this wouldn= =E2=80=99t provide updated kernel staging source, particularly with respect= to any updated includes
  • wasn=E2=80=99t sure what would b= e propagated into the sysroot
  • should consider the backports us= e case that patches the kernel source and then perhaps use this to generate= patchset to be added to kernel recipe (bbappend)
    • otherwise need to ensure proper = handling of sysroot, staging, (as well as a notion of providers and/or alte= rnatives like I mentioned earlier)

&nbs= p;

I haven= =E2=80=99t touched this in years, but perhaps it may help a bit.=

&nbs= p;

I think y= our best bet for short term is to use it to patch the kernel and then captu= re the changes as a patchset to add to a kernel recipe.

&nbs= p;

&nbs= p;

 

Regards,

 

Darcy

 

Darcy Watkins ::  Senior Staff Engineer, Firmware

 

SIERRA WIRELESS

Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604 231 1100

13811 Wireless Way  :: Richmond, BC Canada V6V 3A4

[P2]

dwatkins@sierrawireless.co= m :: www.sierrawireless.com<= /span>

&nbs= p;

From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproje= ct.org] On Behalf Of Marlon Smith
Sent: October-18-17 3:14 PM
To: yocto@yoctoproject.org
Subject: [yocto] Building kernel backports for ARM with Yocto

 

Hi everyone,

 

I'm trying to build the Linux backports project to g= et updated wifi drivers on an older kernel.  The problem is that when = building backports, it first builds several tools that need to be run nativ= ely before cross-compiling the rest of the project.

 

I know how to write a bitbake recipe to compile nati= vely, and how to write one to build for the target, but I can't figure out = how to combine the two.  The backports project has steps for LTIB:

 

 %Build
 export PATH=3D$UNSPOOF_PATH
 
 make menuconfig prefix=3D%{_prefix} \
   CROSS_COMPILE=3D${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX}=
 \
   ARCH=3D$LINTARCH KLIB=3D${TOP}/rootfs/lib/modules/%{kvers=
ion} \
   KLIB_BUILD=3D${TOP}/rpm/BUILD/linux
 
 export PATH=3D$SPOOF_PATH
 
 make prefix=3D%{_prefix} \
   CROSS_COMPILE=3D${TOOLCHAIN_PATH}/bin/${TOOLCHAIN_PREFIX}=
 \
   ARCH=3D$LINTARCH KLIB=3D${TOP}/rootfs/lib/modules/%{kvers=
ion} \
   KLIB_BUILD=3D${TOP}/rpm/BUILD/linux
 
I believe what I need is an equivalent to the line export PA=
TH=3D$UNSPOOF_PATH but I can't find anything in the Yocto documentation =
or mailing lists that would be equivalent to that.
 
Any help would be much appreciated!
 
Thanks
 
Marlon
--=-tNSuzgkwgZqoqBIoNQYO--