From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <Bruce.Ashfield@windriver.com>
Received: from mail1.windriver.com (mail1.windriver.com [147.11.146.13])
	by yocto-www.yoctoproject.org (Postfix) with ESMTP id A00EAE01560
	for <yocto@yoctoproject.org>; Wed, 12 Jun 2013 05:50:02 -0700 (PDT)
Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com
	[147.11.189.40])
	by mail1.windriver.com (8.14.5/8.14.3) with ESMTP id r5CCo09s013629
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Wed, 12 Jun 2013 05:50:01 -0700 (PDT)
Received: from [128.224.146.67] (128.224.146.67) by ALA-HCA.corp.ad.wrs.com
	(147.11.189.50) with Microsoft SMTP Server id 14.2.342.3;
	Wed, 12 Jun 2013 05:49:59 -0700
Message-ID: <51B86E76.5000604@windriver.com>
Date: Wed, 12 Jun 2013 08:49:58 -0400
From: Bruce Ashfield <bruce.ashfield@windriver.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Javi Roman <javiroman@kernel-labs.org>
References: <CACWQdqCvEU3x0ctvUUrMhCAcoxnU0=SpVuW4E7Zo-ret9vidcA@mail.gmail.com>
	<51B732EF.9080902@windriver.com>
	<CACWQdqC6UwX7jYgxp-aRE4pUBz3G=npAAyBRuv3OJQQ_9Y4X_w@mail.gmail.com>
	<1494443.7oZTxQ4oFI@helios>
	<CACWQdqBr9H12g+CTG_yz9zuwgcvRyy1fz=vBxcPXTPQEa5oKEg@mail.gmail.com>
In-Reply-To: <CACWQdqBr9H12g+CTG_yz9zuwgcvRyy1fz=vBxcPXTPQEa5oKEg@mail.gmail.com>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>, yocto@yoctoproject.org
Subject: Re: Custom kernel in Yocto/dylan branch.
X-BeenThere: yocto@yoctoproject.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Discussion of all things Yocto Project <yocto.yoctoproject.org>
List-Unsubscribe: <https://lists.yoctoproject.org/options/yocto>,
	<mailto:yocto-request@yoctoproject.org?subject=unsubscribe>
List-Archive: <http://lists.yoctoproject.org/pipermail/yocto>
List-Post: <mailto:yocto@yoctoproject.org>
List-Help: <mailto:yocto-request@yoctoproject.org?subject=help>
List-Subscribe: <https://lists.yoctoproject.org/listinfo/yocto>,
	<mailto:yocto-request@yoctoproject.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jun 2013 12:50:04 -0000
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 13-06-12 08:37 AM, Javi Roman wrote:
> Hi!
>
> Thank you for your help.
>
> Finally I've had to change the meta/classes/kernel.bbclass in order to
> fix the copy of defconfig to .config:
>
> -  if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
> + if [ -f "${WORKDIR}/defconfig" ]; then
>                  cp "${WORKDIR}/defconfig" "${B}/.config"
> fi
>

Right. That check is what prevents the fallback defconfig processing
from clobbering the .config which is generated by a linux-yocto* based
kernel configuration task (which gives you defconfig + fragments).

The point is that in the linux-yocto "configme" task essentially the
same thing that happens. The defconfig is fed into the configuration
as the baseline config, applied after a "allnoconfig" and then has
any fragments layered on top.

Which again leads me to my question about what exactly you were
seeing before that change in the linux build directory as the .config ?

Cheers,

Bruce

> I don't know the exact problem, and I'm trying to find out it.
>
> Cheers.
>
> Javi Roman
>
>
> On Tue, Jun 11, 2013 at 5:34 PM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
>> On Tuesday 11 June 2013 16:47:53 Javi Roman wrote:
>>> With
>>>
>>> SRC_URI_append = "file://defconfig"
>>
>> Does your actual recipe have a leading space in the value? _append won't add
>> this for you so you have to do it explicitly.
>>
>> Cheers,
>> Paul
>>
>> --
>>
>> Paul Eggleton
>> Intel Open Source Technology Centre