From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id E13A8E0055D for ; Thu, 28 Nov 2013 07:37:24 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so14770842iej.12 for ; Thu, 28 Nov 2013 07:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sNYxibbaZCQwiewUkAWKVrngCSuKFxiHNkPn1OHTH5Y=; b=ehwnJEC4t/FUZ5e1o+r1EOrZ6L57GX8W6rJKDtC1Ni4IJww0DTYQJrkUDYV2SUoapl Es730qx1wItTdWuwUBfeIa3KqY/jtcNtE9pWvA8QZgfVA+oeBe5DylAxhhglVhNnYCy8 Cv8i1oN0EWN+OlBj1CtsdEHT1Eh4hZ1GNdfCqWxHJySGQ38tzTlOlxZ9Aa+HPoApOKrA mZjfILNSzQkK/bdi21PVcNlMUEmnXZJ0IS1YQgEbWuGoSh+QVo1Y2Ilp6IcLs2glPudJ g4FHgVuFn2xREkSPLLKaJR1JB7ezLI/1i7SGa01Sp83+5qlE1a/NeGJRJAr4aK2fazWj ow0w== X-Received: by 10.43.178.135 with SMTP id ow7mr12759926icc.43.1385653043639; Thu, 28 Nov 2013 07:37:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.26.233 with HTTP; Thu, 28 Nov 2013 07:37:03 -0800 (PST) In-Reply-To: <52771111.5000604@windriver.com> References: <525FE3C9.3070003@windriver.com> <5260BDA6.4020807@windriver.com> <5261974C.7010202@windriver.com> <5266A665.8030303@alphalem.com> <52686723.4080305@windriver.com> <526B18BC.5050302@alphalem.com> <526ECFF3.4060207@windriver.com> <52771111.5000604@windriver.com> From: Diego Sueiro Date: Thu, 28 Nov 2013 13:37:03 -0200 Message-ID: To: Bruce Ashfield Cc: "yocto@yoctoproject.org" , Paul Eggleton Subject: Re: Custom defconfig is not used 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: Thu, 28 Nov 2013 15:37:25 -0000 Content-Type: multipart/alternative; boundary=001a11c30bec72bf7204ec3e7d5b --001a11c30bec72bf7204ec3e7d5b Content-Type: text/plain; charset=ISO-8859-1 Bruce, Any updates on this? Regards, -- *dS Diego Sueiro /*long live rock 'n roll*/ On Mon, Nov 4, 2013 at 1:14 AM, Bruce Ashfield wrote: > On 13-10-29 11:31 AM, Diego Sueiro wrote: > >> Bruce, >> >> I've created new build setup with this configuration: >> >> BB_VERSION = "1.18.0" >> BUILD_SYS = "x86_64-linux" >> NATIVELSBSTRING = "Ubuntu-12.10" >> TARGET_SYS = "arm-poky-linux-gnueabi" >> MACHINE = "beaglebone" >> DISTRO = "poky" >> DISTRO_VERSION = "1.4.2" >> TUNE_FEATURES = "armv7a vfp neon" >> TARGET_FPU = "vfp-neon" >> meta >> meta-yocto >> meta-yocto-bsp = "dylan:4e399f08d596197859214fdb3b06403b87bf8789" >> meta-oe = "dylan:a108b2203a997634f87ac687e81712badaf3c546" >> common-bsp = "dylan:7fdf9c670a10c5031a2d5555c15c45e453de8c21" >> meta-mine = "dylan:4e399f08d596197859214fdb3b06403b87bf8789" >> >> common-bsp comes from meta-beagleboard. >> meta-oe needed to be added because of machine_kernel_pr.bbclass. >> >> bblayers.conf: >> >> LCONF_VERSION = "6" >> BBPATH = "${TOPDIR}" >> BBFILES ?= "" >> BBLAYERS ?= " \ >> ${TOPDIR}/meta \ >> ${TOPDIR}/meta-yocto \ >> ${TOPDIR}/meta-yocto-bsp \ >> ${TOPDIR}/meta-openembedded/meta-oe \ >> ${TOPDIR}/meta-beagleboard/common-bsp \ >> ${TOPDIR}/meta-mine \ >> " >> >> meta-mine: >> >> conf/layer.conf: >> >> BBPATH .= ":${LAYERDIR}" >> BBFILES += "${LAYERDIR}/recipes*/*/*.bb >> ${LAYERDIR}/recipes*/*/*.bbappend" >> BBFILE_COLLECTIONS += "my-layer" >> BBFILE_PATTERN_my-layer := "^${LAYERDIR}/" >> BBFILE_PRIORITY_my-layer = "10" >> >> recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 1): >> >> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:" >> COMPATIBLE_MACHINE_beaglebone = "(beaglebone)" >> SRC_URI += " file://defconfig \ >> " >> >> recipes-kernel/linux/linux-mainline-3.8/defconfig (scenario 1): >> >> http://pastebin.com/qd8B3C5K >> >> >> recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 2): >> >> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:" >> inherit kernel >> require recipes-kernel/linux/linux-yocto.inc >> COMPATIBLE_MACHINE_beaglebone = "(beaglebone)" >> SRC_URI += " file://config-addons.cfg \ >> " >> >> recipes-kernel/linux/linux-mainline-3.8/config-addons.cfg (scenario >> 2): >> >> CONFIG_WATCHDOG_NOWAYOUT=y >> >> CONFIG_NTFS_FS=y >> CONFIG_NTFS_RW=y >> >> >> >> Results: >> >> * Scenario 1: Full defconfig replacement >> >> >> ${WORKDIR}/defconfig comes from meta-beagleboard instead of meta-mine >> >> ${S}/.config comes from meta-beagleboard instead of meta-mine >> > > FYI: I went silent on this, since I was running a few experiments in the > background. Mainly on scenario 2, but I can say that I see the same > behaviour > with scenario #1 as you do. Whether or not I use the yocto kernel tooling, > or the core kernel processing, I see exactly the same defconfig used. > > The issue you are seeing is distinct from the kernel processing, since > the defconfig isn't treated any differently than anything else on the > SRC_URI from the fetcher point of view ... and it is the fetcher which > is matching file://defconfig from the meta-beagleboard layer before the > one you have in meta-mine, since FILESEXTRAPATHS are searched after the > FILESPATH for the elements in the SRC_URI. But I'm not a fetcher expert, > that's my understanding and empirical evidence. > > As a debug, I called src_patches() in patches.bbclass explicitly, and > it is obvious that the source of the defconfig is from meta-beagleboard. > Renaming the file in meta-beagleboard, allows the one in meta-mine to > be found, since the search continues. > > So for this question, your issue is with the ordering of the elements > on the SRC_URI, and you can have your layer prioritized by making sure > it is in the search paths first. > > This may or may not contradict the docs, and there are several threads > ongoing about SRC_URI ordering in the various branches .. so I'm simply > watching and waiting on this one. > > >> * Scenario 2: Config fragments >> >> >> "bitbake linux-mainline" got stuck on do_patch >> >> log.do_patch: >> >> DEBUG: Executing shell function do_patch >> >> WARNING: no meta data branch found ... >> >> Switched to branch 'linux-3.8.y' >> >> [INFO] validating against known patches >> (beaglebone-standard-meta) >> >> > As for this. I debugged it over the weekend, and you wouldn't see this on > master, but the tools on the dylan branch aren't using the proper > kern-tools > SRCREVS. As such, I backported a change from master, and switched the > kern-tools to use the dylan branch. > > What you were seeing as a hang, was really just an extremely long run > of the patch processing, the 700+ patches in the beagleboard kernel > recipe were being detected multiple times, and expanding to 47K entries. > > Which the patch I've attached here, I was able to patch and configure the > kernel with the same layers. Note: the run still takes a long time, since > even applying 700 patches at a couple of seconds per patch .. takes a > good chunk of time. > > I've added Paul Eggleton to the cc: list, since I'm not sure if dylan is > still being updated, but if it is, the patch I'm attaching should be > applied to fix the kern-tools situation in that branch. > > Cheers, > > Bruce > > >> >> Regards, >> >> -- >> *dS >> Diego Sueiro >> >> /*long live rock 'n roll*/ >> >> >> 2013/10/29 Diego Sueiro > > >> >> 2013/10/29 Andrea Adami > > >> >> >> I'll jump in one more time... >> >> Have you tried putting defconfig and patch under subdir? >> >> recipes-kernel/linux/linux-yocto-3.2/ >> defconfig >> my-own.patch >> >> I've recently added two similar entries for 3.10 and it works. >> Afaik it was impossible to put a common patch under >> /linux-yocto-.3.2 >> at the time. >> >> >> Andrea, >> >> I did it before and not worked. >> I'll do it again just to make sure. >> >> >> Regards, >> >> -- >> *dS >> Diego Sueiro >> >> /*long live rock 'n roll*/ >> >> >> 2013/10/29 Andrea Adami > > >> >> >> On Tue, Oct 29, 2013 at 11:33 AM, Diego Sueiro >> > wrote: >> > >> > 2013/10/28 Bruce Ashfield > > >> >> >> >> >> I'm using dylan for my yocto checkout (not oe-core >> standalone, since >> >> this is a yocto list/question), >> > >> > I thought that opemenbedded-core and poky were sharing the >> same core >> > components, classes and functions. >> > >> >> >> >> My build shows: >> >> >> >> meta >> >> meta-yocto >> >> meta-yocto-bsp = >> "dylan:3dc4505f0e744177ae4ddff1e1ce8b31b95dfaa6" >> >> meta-ti = >> "master:c14c386946e1ea341faeea292580e37d538d645d" >> >> meta-alphalem = >> "master:a5c0e8ff51297a4090cd47d669b4fc9c94696908" >> >> meta-alphalem-bsp = >> "master:56086e4dc618e975c9a46491793041f0d18e47a2" >> >> >> >> Mike indicated that he was using dylan for meta-ti, but that >> doesn't >> >> make a difference either, since for our purposed. It's >> kernel.bbclass >> >> and the yocto kernel processing that matters. >> > >> > I'll build a setup with yocto (dylan), meta-beagleboard >> (dylan) and >> > meta-mine to check if I can reproduce the issues. >> > >> >> >> >> In meta-alphalem-bsp, I have linux-mainline_3.2.bbappend, >> with the >> >> following content: >> >> >> >> > cat linux-mainline_3.2.bbappend >> >> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.2:" >> >> >> >> inherit kernel >> >> require recipes-kernel/linux/linux-yocto.inc >> >> >> >> COMPATIBLE_MACHINE = "(beagleboard)" >> >> >> >> SRC_URI_append = " file://defconfig" >> >> SRC_URI_append = " file://my_frag.cfg" >> >> >> >> And I added a fragment which has: >> >> >> >> > cat my_frag.cfg >> >> CONFIG_WATCHDOG_NOWAYOUT=y >> >> CONFIG_NTFS_FS=y >> >> CONFIG_NTFS_RW=y >> >> >> >> When both are applied to the kernel build, we should see >> CONFIG_NTFS_FS >> >> transition from =m to =y: >> >> >> >> > grep CONFIG_NTFS_FS * >> >> defconfig:CONFIG_NTFS_FS=m >> >> my_frag.cfg:CONFIG_NTFS_FS=y >> >> >> >> After invoking linux-mainline's configure task, I see the >> following: >> >> >> >> > grep CONFIG_NTFS_FS linux-beagleboard-standard- >> build/.config >> >> CONFIG_NTFS_FS=y >> >> >> >> And other elements of the defconfig and fragment are >> properly applied >> >> to the configuration phase. >> >> >> >> I'm also seeing good results on master, which means that I'm >> at a >> >> standstill to reproduce any problems. >> >> >> >> Diego: can you confirm for me what triggers you are seeing >> that shows >> >> the defconfig and fragment are not used. I assume the config >> options >> >> are not present, but I just want to be sure. >> > >> > For the full defconfig replacement after doing a do_configure >> I've checked >> > .config on ${S} and it did not included my CONFIGS. >> > For config fragment it got stuck on do_patch task. >> > >> > >> > >> > Regards, >> > >> > -- >> > *dS >> > Diego Sueiro >> > >> > /*long live rock 'n roll*/ >> > >> > _______________________________________________ >> > yocto mailing list >> > yocto@yoctoproject.org >> >> > https://lists.yoctoproject.org/listinfo/yocto >> > >> >> I'll jump in one more time... >> >> Have you tried putting defconfig and patch under subdir? >> >> recipes-kernel/linux/linux-yocto-3.2/ >> defconfig >> my-own.patch >> >> I've recently added two similar entries for 3.10 and it works. >> Afaik it was impossible to put a common patch under >> /linux-yocto-.3.2 >> at the time. >> >> Regards >> >> Andrea >> >> >> >> > --001a11c30bec72bf7204ec3e7d5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Bruce,

Any updates on this?
=

Reg= ards,

--
*dS
Diego Sueiro

/*long live rock= 'n roll*/


On Mon, Nov 4, 2013 at 1:14 AM, Bruce As= hfield <bruce.ashfield@windriver.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On 13-10-29 11:31 AM, Diego Sueiro wrote:
Bruce,

I've created new build setup with this configuration:

=A0 =A0 BB_VERSION =A0 =A0 =A0 =A0=3D "1.18.0"
=A0 =A0 BUILD_SYS =A0 =A0 =A0 =A0 =3D "x86_64-linux"
=A0 =A0 NATIVELSBSTRING =A0 =3D "Ubuntu-12.10"
=A0 =A0 TARGET_SYS =A0 =A0 =A0 =A0=3D "arm-poky-linux-gnueabi" =A0 =A0 MACHINE =A0 =A0 =A0 =A0 =A0 =3D "beaglebone"
=A0 =A0 DISTRO =A0 =A0 =A0 =A0 =A0 =A0=3D "poky"
=A0 =A0 DISTRO_VERSION =A0 =A0=3D "1.4.2"
=A0 =A0 TUNE_FEATURES =A0 =A0 =3D "armv7a vfp neon"
=A0 =A0 TARGET_FPU =A0 =A0 =A0 =A0=3D "vfp-neon"
=A0 =A0 meta
=A0 =A0 meta-yocto
=A0 =A0 meta-yocto-bsp =A0 =A0=3D "dylan:4e399f08d596197859214f= db3b06403b87bf8789"
=A0 =A0 meta-oe =A0 =A0 =A0 =A0 =A0 =3D "dylan:a108b2203a997634= f87ac687e81712badaf3c546"
=A0 =A0 common-bsp =A0 =A0 =A0 =A0=3D "dylan:7fdf9c670a10c5031a= 2d5555c15c45e453de8c21"
=A0 =A0 meta-mine =A0 =A0 =A0 =A0 =3D "dylan:4e399f08d596197859= 214fdb3b06403b87bf8789"

common-bsp comes from meta-beagleboard.
meta-oe needed to be added because of machine_kernel_pr.bbclass.

bblayers.conf:

=A0 =A0 LCONF_VERSION =3D "6"
=A0 =A0 BBPATH =3D "${TOPDIR}"
=A0 =A0 BBFILES ?=3D ""
=A0 =A0 BBLAYERS ?=3D " \
=A0 =A0 =A0 =A0${TOPDIR}/meta \
=A0 =A0 =A0 =A0${TOPDIR}/meta-yocto \
=A0 =A0 =A0 =A0${TOPDIR}/meta-yocto-bsp \
=A0 =A0 =A0 =A0${TOPDIR}/meta-openembedded/meta-oe \
=A0 =A0 =A0 =A0${TOPDIR}/meta-beagleboard/common-bsp \
=A0 =A0 =A0 =A0${TOPDIR}/meta-mine \
=A0 =A0 =A0 =A0"

meta-mine:

=A0 =A0 conf/layer.conf:

=A0 =A0 =A0 =A0 BBPATH .=3D ":${LAYERDIR}"
=A0 =A0 =A0 =A0 BBFILES +=3D "${LAYERDIR}/recipes*/*/*.bb
=A0 =A0 =A0 =A0 ${LAYERDIR}/recipes*/*/*.bbappend"
=A0 =A0 =A0 =A0 BBFILE_COLLECTIONS +=3D "my-layer"
=A0 =A0 =A0 =A0 BBFILE_PATTERN_my-layer :=3D "^${LAYERDIR}/"
=A0 =A0 =A0 =A0 BBFILE_PRIORITY_my-layer =3D "10"

=A0 =A0 recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 1= ):

=A0 =A0 =A0 =A0 FILESEXTRAPATHS_prepend :=3D "${THISDIR}/${PN}-3.8:&qu= ot;
=A0 =A0 =A0 =A0 COMPATIBLE_MACHINE_beaglebone =3D "(beaglebone)"<= br> =A0 =A0 =A0 =A0 SRC_URI +=3D " file://defconfig \
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "

=A0 =A0 recipes-kernel/linux/linux-mainline-3.8/defconfig (scenario = 1):

=A0 =A0 =A0 =A0 = http://pastebin.com/qd8B3C5K


=A0 =A0 recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 2= ):

=A0 =A0 =A0 =A0 FILESEXTRAPATHS_prepend :=3D "${THISDIR}/${PN}-3.8:&qu= ot;
=A0 =A0 =A0 =A0 inherit kernel
=A0 =A0 =A0 =A0 require recipes-kernel/linux/linux-yocto.inc
=A0 =A0 =A0 =A0 COMPATIBLE_MACHINE_beaglebone =3D "(beaglebone)"<= br> =A0 =A0 =A0 =A0 SRC_URI +=3D " file://config-addons.cfg \
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "

=A0 =A0 recipes-kernel/linux/linux-mainline-3.8/config-addons.cfg (s= cenario 2):

=A0 =A0 =A0 =A0 CONFIG_WATCHDOG_NOWAYOUT=3Dy

=A0 =A0 =A0 =A0 CONFIG_NTFS_FS=3Dy
=A0 =A0 =A0 =A0 CONFIG_NTFS_RW=3Dy



Results:

=A0 * Scenario 1: Full defconfig replacement


=A0 =A0 ${WORKDIR}/defconfig comes from meta-beagleboard instead of meta-mi= ne

=A0 =A0 ${S}/.config comes from meta-beagleboard instead of meta-mine

FYI: I went silent on this, since I was running a few experiments in the background. Mainly on scenario 2, but I can say that I see the same behavio= ur
with scenario #1 as you do. Whether or not I use the yocto kernel tooling,<= br> or the core kernel processing, I see exactly the same defconfig used.

The issue you are seeing is distinct from the kernel processing, since
the defconfig isn't treated any differently than anything else on the SRC_URI from the fetcher point of view ... and it is the fetcher which
is matching file://defconfig from the meta-beagleboard layer before the
one you have in meta-mine, since FILESEXTRAPATHS are searched after the
FILESPATH for the elements in the SRC_URI. But I'm not a fetcher expert= ,
that's my understanding and empirical evidence.

As a debug, I called src_patches() in patches.bbclass explicitly, and
it is obvious that the source of the defconfig is from meta-beagleboard. Renaming the file in meta-beagleboard, allows the one in meta-mine to
be found, since the search continues.

So for this question, your issue is with the ordering of the elements
on the SRC_URI, and you can have your layer prioritized by making sure
it is in the search paths first.

This may or may not contradict the docs, and there are several threads
ongoing about SRC_URI ordering in the various branches .. so I'm simply=
watching and waiting on this one.


=A0 * Scenario 2: Config fragments


=A0 =A0 "bitbake linux-mainline" got stuck on do_patch

=A0 =A0 log.do_patch:

=A0 =A0 =A0 =A0 DEBUG: Executing shell function do_patch

=A0 =A0 =A0 =A0 WARNING: no meta data branch found ...

=A0 =A0 =A0 =A0 Switched to branch 'linux-3.8.y'

=A0 =A0 =A0 =A0 [INFO] validating against known patches =A0(beaglebone-stan= dard-meta)


As for this. I debugged it over the weekend, and you wouldn't see this = on
master, but the tools on the dylan branch aren't using the proper kern-= tools
SRCREVS. As such, I backported a change from master, and switched the
kern-tools to use the dylan branch.

What you were seeing as a hang, was really just an extremely long run
of the patch processing, the 700+ patches in the beagleboard kernel
recipe were being detected multiple times, and expanding to 47K entries.
Which the patch I've attached here, I was able to patch and configure t= he
kernel with the same layers. =A0Note: the run still takes a long time, sinc= e
even applying 700 patches at a couple of seconds per patch .. takes a
good chunk of time.

I've added Paul Eggleton to the cc: list, since I'm not sure if dyl= an is
still being updated, but if it is, the patch I'm attaching should be applied to fix the kern-tools situation in that branch.

Cheers,

Bruce



Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


2013/10/29 Diego Sueiro <diego.sueiro@gmail.com
<mailto:dieg= o.sueiro@gmail.com>>

=A0 =A0 2013/10/29 Andrea Adami <andrea.adami@gmail.com
=A0 =A0 <mailto:andrea.adami@gmail.com>>


=A0 =A0 =A0 =A0 I'll jump in one more time...

=A0 =A0 =A0 =A0 Have you tried putting defconfig and patch under <machin= e> subdir?

=A0 =A0 =A0 =A0 recipes-kernel/linux/linux-yocto-3.2/<machine>=
=A0 =A0 =A0 =A0 defconfig
=A0 =A0 =A0 =A0 my-own.patch

=A0 =A0 =A0 =A0 I've recently added two similar entries for 3.10 and it= works.
=A0 =A0 =A0 =A0 Afaik it was impossible to put a common patch under
=A0 =A0 =A0 =A0 /linux-yocto-.3.2
=A0 =A0 =A0 =A0 at the time.


=A0 =A0 Andrea,

=A0 =A0 I did it before and not worked.
=A0 =A0 I'll do it again just to make sure.


=A0 =A0 Regards,

=A0 =A0 --
=A0 =A0 *dS
=A0 =A0 Diego Sueiro

=A0 =A0 /*long live rock 'n roll*/


=A0 =A0 2013/10/29 Andrea Adami <andrea.adami@gmail.com
=A0 =A0 <mailto:andrea.adami@gmail.com>>


=A0 =A0 =A0 =A0 On Tue, Oct 29, 2013 at 11:33 AM, Diego Sueiro
=A0 =A0 =A0 =A0 <diego.sueiro@gmail.com <mailto:diego.sueiro@gmail.com>> wrote= :
=A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0> 2013/10/28 Bruce Ashfield <bruce.ashfield@windriver.com
=A0 =A0 =A0 =A0 <mailto:bruce.ashfield@windriver.com>>

=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> I'm using dylan for my yocto checkout (not = oe-core
=A0 =A0 =A0 =A0 standalone, since
=A0 =A0 =A0 =A0 =A0>> this is a yocto list/question),
=A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0> I thought that opemenbedded-core and poky were shar= ing the
=A0 =A0 =A0 =A0 same core
=A0 =A0 =A0 =A0 =A0> components, classes and functions.
=A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> My build shows:
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> meta
=A0 =A0 =A0 =A0 =A0>> meta-yocto
=A0 =A0 =A0 =A0 =A0>> meta-yocto-bsp =A0 =A0=3D
=A0 =A0 =A0 =A0 "dylan:3dc4505f0e744177ae4ddff1e1ce8b31b= 95dfaa6"
=A0 =A0 =A0 =A0 =A0>> meta-ti =A0 =A0 =A0 =A0 =A0 =3D
=A0 =A0 =A0 =A0 "master:c14c386946e1ea341faeea292580e37d= 538d645d"
=A0 =A0 =A0 =A0 =A0>> meta-alphalem =A0 =A0 =3D
=A0 =A0 =A0 =A0 "master:a5c0e8ff51297a4090cd47d669b4fc9c= 94696908"
=A0 =A0 =A0 =A0 =A0>> meta-alphalem-bsp =3D
=A0 =A0 =A0 =A0 "master:56086e4dc618e975c9a46491793041f0= d18e47a2"
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> Mike indicated that he was using dylan for meta= -ti, but that
=A0 =A0 =A0 =A0 doesn't
=A0 =A0 =A0 =A0 =A0>> make a difference either, since for our purpose= d. It's
=A0 =A0 =A0 =A0 kernel.bbclass
=A0 =A0 =A0 =A0 =A0>> and the yocto kernel processing that matters. =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0> I'll build a setup with yocto (dylan), meta-bea= gleboard
=A0 =A0 =A0 =A0 (dylan) and
=A0 =A0 =A0 =A0 =A0> meta-mine to check if I can reproduce the issues. =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> In meta-alphalem-bsp, I have linux-mainline_3.2= .bbappend,
=A0 =A0 =A0 =A0 with the
=A0 =A0 =A0 =A0 =A0>> following content:
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> > cat linux-mainline_3.2.bbappend
=A0 =A0 =A0 =A0 =A0>> FILESEXTRAPATHS_prepend :=3D "${THISDIR}/$= {PN}-3.2:"
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> inherit kernel
=A0 =A0 =A0 =A0 =A0>> require recipes-kernel/linux/linux-yocto= .inc
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> COMPATIBLE_MACHINE =3D "(beagleboard)"= ;
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> SRC_URI_append =3D " file://defconfig"= ;
=A0 =A0 =A0 =A0 =A0>> SRC_URI_append =3D " file://my_frag.cfg&qu= ot;
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> And I added a fragment which has:
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> > cat my_frag.cfg
=A0 =A0 =A0 =A0 =A0>> CONFIG_WATCHDOG_NOWAYOUT=3Dy
=A0 =A0 =A0 =A0 =A0>> CONFIG_NTFS_FS=3Dy
=A0 =A0 =A0 =A0 =A0>> CONFIG_NTFS_RW=3Dy
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> When both are applied to the kernel build, we s= hould see
=A0 =A0 =A0 =A0 CONFIG_NTFS_FS
=A0 =A0 =A0 =A0 =A0>> transition from =3Dm to =3Dy:
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> > grep CONFIG_NTFS_FS *
=A0 =A0 =A0 =A0 =A0>> defconfig:CONFIG_NTFS_FS=3Dm
=A0 =A0 =A0 =A0 =A0>> my_frag.cfg:CONFIG_NTFS_FS=3Dy
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> After invoking linux-mainline's configure t= ask, I see the
=A0 =A0 =A0 =A0 following:
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> > grep CONFIG_NTFS_FS linux-beagleboard-stan= dard-build/.config
=A0 =A0 =A0 =A0 =A0>> CONFIG_NTFS_FS=3Dy
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> And other elements of the defconfig and fragmen= t are
=A0 =A0 =A0 =A0 properly applied
=A0 =A0 =A0 =A0 =A0>> to the configuration phase.
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> I'm also seeing good results on master, whi= ch means that I'm
=A0 =A0 =A0 =A0 at a
=A0 =A0 =A0 =A0 =A0>> standstill to reproduce any problems.
=A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0>> Diego: can you confirm for me what triggers you= are seeing
=A0 =A0 =A0 =A0 that shows
=A0 =A0 =A0 =A0 =A0>> the defconfig and fragment are not used. I assu= me the config
=A0 =A0 =A0 =A0 options
=A0 =A0 =A0 =A0 =A0>> are not present, but I just want to be sure. =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0> For the full defconfig replacement after doing a do= _configure
=A0 =A0 =A0 =A0 I've checked
=A0 =A0 =A0 =A0 =A0> .config on ${S} and it did not included my CONFIGS.=
=A0 =A0 =A0 =A0 =A0> For config fragment it got stuck on do_patch task.<= br> =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0> Regards,
=A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0> --
=A0 =A0 =A0 =A0 =A0> *dS
=A0 =A0 =A0 =A0 =A0> Diego Sueiro
=A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0> /*long live rock 'n roll*/
=A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0> ____________________________________________= ___
=A0 =A0 =A0 =A0 =A0> yocto mailing list
=A0 =A0 =A0 =A0 =A0> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>

=A0 =A0 =A0 =A0 =A0> https://lists.yoctoproject.org/listinfo/yoc= to
=A0 =A0 =A0 =A0 =A0>

=A0 =A0 =A0 =A0 I'll jump in one more time...

=A0 =A0 =A0 =A0 Have you tried putting defconfig and patch under <machin= e> subdir?

=A0 =A0 =A0 =A0 recipes-kernel/linux/linux-yocto-3.2/<machine>=
=A0 =A0 =A0 =A0 defconfig
=A0 =A0 =A0 =A0 my-own.patch

=A0 =A0 =A0 =A0 I've recently added two similar entries for 3.10 and it= works.
=A0 =A0 =A0 =A0 Afaik it was impossible to put a common patch under
=A0 =A0 =A0 =A0 /linux-yocto-.3.2
=A0 =A0 =A0 =A0 at the time.

=A0 =A0 =A0 =A0 Regards

=A0 =A0 =A0 =A0 Andrea





--001a11c30bec72bf7204ec3e7d5b--