On Wed, Oct 23, 2013 at 3:07 AM, matti kaasinen
<matti.kaasi...@gmail.com> wrote:
> Hi Ulf,
> Yes, linux.inc seems doing the job as you told - this clears a lot. I had
> been patching wrong file:${S}/defconfig instead of ${WORKDIR}/defconfig.
> It seems that I'm not alone with this mistake. ${S}/defconfig seems to be
> created by two patches:
> 0002-add-defconfig-file-to-use-as-.config.patch makes skeleton and
> 0073-defconfig-Update-bone-default-config.patch makes some modefications.
>
> ${WORKDIR}/defconfig (important one) is most likely coming from
> ...../linux/linux-mainline-3.8/beaglebone/defconfig as there is only one
> difference that could have come from configuration process.
>
> It seems that configuration fragments do not work in regular Angstrom - I
> suppose they are just Yocto stuff.
yes.
> Providing defconfig directly did not work - most likely it was written over
> by the patching the seems creating the ${WORKDIR}/defconfig
what do you mean ? defconfig is provided as any other file and then munged over
in WORKDIR to make a .config
usually you would keep the complete defconfig in your layer and use
it. You would start
with the given reference defconfig and tweak it to your interest and then do
make savedefconfig
which should generate a defconfig like arch/arm/configs which then you
can save as a defconfig
file in your layer and use it to replace the defconfig file that
meta-beagleboard is providing
>
> Downside is that my beaglebone version of defconfig seems to get used
> instead of mine even though my layer should have higher priority. I hope
> this is the last thing I should cleared.
for conf and include files it will use the BBPATH and not priority
which means your layer should appear before meta-beagleboard in BBPATH
order.
>
> Thanks,
> Matti
>
>
> 2013/10/22 Ulf Samuelsson <angstrom-...@emagii.com>
>
>> On 2013-10-22 17:20, matti kaasinen wrote:
>>
>>> Thanks Ulf,
>>> It seems to work in that way. However, I'm a bit surprised that it works
>>> so
>>> as as I mentioned above all the procedures -
>>> patching defconfig in the kernel build directory, providing defconfig in
>>> metadata and providing configuration fragments as described in the Yocto
>>> Kernel development manual - give the same outcome in the defconfig at the
>>> kernel build directory.
>>>
>>
>> What is happening is dependent on the kernel recipe.
>>
>> Typically, you find that "linux.inc" does the job,
>> and in "do_configure", which is run when you do:
>>
>> bitbake -c configure virtual/kernel
>>
>> ${WORKDIR}/defconfig is altered to ensure it makes sense.
>> A lot of options are simply deleted.
>> ${S}/.config" is created as an empty file and then the deleted options are
>> added with a proper value.
>> At the end, defconfig is appended to the "${S}/.config
>>
>> so when you run
>>
>> bitbake -c configure virtual/kernel
>>
>> both ${WORKDIR}/defconfig and ${S}/.config are changed.
>>
>> /Ulf
>>
>>
>> What command do you use when you are using .config directly? My experience
>>> is that when I for instance run:
>>> bitbake -f -c configure virtual/kernel
>>> after
>>> bitbake -f -c patch virtual/kernel
>>> bitbake executes again do_patch, that at least rides over defconfig if I
>>> edited that.
>>>
>>> In fact it seems that "bitbake -c config" runs always do_patch even if
>>> previous command was patch and no modifications were in between.
>>>
>>> BR,
>>> Matti
>>>
>>>
>>> 2013/10/22 Ulf Samuelsson <angstrom-...@emagii.com>
>>>
>>> The "defconfig" file is present in the meta-layers and copied to the
>>>> kernel build directory.
>>>> It is used to create the ".config" file in the kernel source directory.
>>>>
>>>> If you modify the ".config" file, you will see changes in the kernel
>>>> file.
>>>> if you modify the defconfig file in the build directory, nothing happens.
>>>>
>>>> I typically change the ".config" and copy the result to the "defconfig"
>>>> in
>>>> the
>>>> meta-layer. Then I rebuild from scratch.
>>>>
>>>> bitbake -c cleansstate virtual/kernel
>>>> bitbake virtual/kernel
>>>>
>>>>
>>>> Best Regards
>>>> Ulf Samuelsson
>>>> u...@emagii.com
>>>> +46 (722) 427 437
>>>>
>>>>
>>>> 22 okt 2013 kl. 14:04 skrev matti kaasinen <matti.kaasi...@gmail.com>:
>>>>
>>>> Hi!
>>>>>
>>>>> What configuration kernel build really uses - .config or defconfig?
>>>>> It seems, that menuconfig (bitbake -c menuconfig ) use always .config
>>>>>
>>>> file.
>>>>
>>>>> I have problem that changes in defconfig are not seen in kernel
>>>>> features.
>>>>> Instead they seem the same that are in .config file
>>>>>
>>>>> I have tried configuration fragments, patches and providing defconfig
>>>>> directly.
>>>>>
>>>>> They all seem to give proper defconfig. However, menuconfig never
>>>>> provide
>>>>> the changed configurations. Also, for instance when I try to configure
>>>>> HW
>>>>> EEC operation for NAND flash using CONFIG_MTD_NAND_OMAP_BCH.
>>>>> omap2.c reports that "CONFIG_MTD_NAND_OMAP_BCH is not enabled".
>>>>>
>>>>> I've been workin on beaglebone variant - layer over beaglebone.
>>>>> Build Configuration:
>>>>> BB_VERSION = "1.17.0"
>>>>> TARGET_ARCH = "arm"
>>>>> TARGET_OS = "linux-gnueabi"
>>>>> MACHINE = "beaglebone"
>>>>> DISTRO = "angstrom"
>>>>> DISTRO_VERSION = "v2012.12"
>>>>> TUNE_FEATURES = "armv7a vfp neon cortexa8"
>>>>> TARGET_FPU = "vfp-neon"
>>>>> oe_sitecno
>>>>> oe_emergence = "<unknown>:<unknown>"
>>>>> meta-angstrom =
>>>>> "angstrom-v2012.12-yocto1.3:**b7f8207b94d9a0ece73ad212a193cb**
>>>>> 2c95bd17ee"
>>>>>
>>>>> These setting give kernel 3.8.11.
>>>>>
>>>>> Is there something I have missed?
>>>>> Thanks in advance,
>>>>> Matti
>>>>> ______________________________**_________________
>>>>> Angstrom-distro-devel mailing list
>>>>> Angstrom-distro-devel@**linuxtogo.org<Angstrom-distro-devel@linuxtogo.org>
>>>>>
>>>>> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**
>>>> angstrom-distro-devel<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel>
>>>>
>>>> ______________________________**_________________
>>>> Angstrom-distro-devel mailing list
>>>> Angstrom-distro-devel@**linuxtogo.org<Angstrom-distro-devel@linuxtogo.org>
>>>> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**
>>>> angstrom-distro-devel<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel>
>>>>
>>>> ______________________________**_________________
>>> Angstrom-distro-devel mailing list
>>> Angstrom-distro-devel@**linuxtogo.org<Angstrom-distro-devel@linuxtogo.org>
>>> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**
>>> angstrom-distro-devel<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel>
>>>
>>
>>
>> ______________________________**_________________
>> Angstrom-distro-devel mailing list
>> Angstrom-distro-devel@**linuxtogo.org<Angstrom-distro-devel@linuxtogo.org>
>> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**
>> angstrom-distro-devel<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel>
>>
> _______________________________________________
> Angstrom-distro-devel mailing list
> Angstrom-distro-devel@linuxtogo.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
_______________________________________________
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
