Re: [Angstrom-devel] what file kernel configuration really uses?
I have noticed this as well and it is highly irritating,
Best Regards
Ulf Samuelsson
28 okt 2013 kl. 09:23 skrev matti kaasinen :
> There is another question, I think I mentioned it earlier also in this
> chain. I have also asked it in other time as own subject. No-one seems to
> have opinion about that.
> Koen, you might know, if it is a "feature" misbehaviour or problem in my
> set-up.
> For instance when I ran those tests I did first "fetch". Then I ran
> "unpack". Unpacking ran again fetch and then unpack. Then I ran "patch".
> Again, at least unpack was run again and then patch. Similar behaviour
> seems to happen with "configure" so that patch will be run again even
> though it had been ran manually before. This feature makes paching quite
> awkward as if I edit some file that has been unpacked and applied with
> other patches, that will be written over when running "configure" or
> "compile" to check how edits worked.
>
> I always get two warnings when I run bitbake:
> WARNING: No recipes available for:
> /home/sw/cpr3/oe/sources/meta-handheld/recipes-core/udev/udev_164.bbappend
>
> /home/sw/cpr3/oe/sources/meta-intel/meta-fri2/recipes-core/tiny-init/tiny-init.bbappend
>
> But I suppose they are nothing to do with this issue.
>
> So, Is this something that should happen or should I try to find set-up
> problem of some kind?
> Thanks,
> Matti
>
>
> 2013/10/28 matti kaasinen
>
>>
>> 2013/10/27 Koen Kooi
>>
>>> On Wed, 2013-10-23 at 14:44 +0300, matti kaasinen wrote:
2013/10/23 Khem Raj
>> 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.
>>
>
What I mean above is that beaglebone folks have made those patches for
>>> some
reason that is not quite clear tome now considering how ${S}/defconfig
>>> is
produced in linux.inc.
>>>
>>> ${S}/defconfig is neither used nor produced by OE.
>>>
>>> I was wrong in that there are two patches that create ${S}/defconfig.
>> Instead there are three of them:
>> 0002-add-defconfig-file-to-use-as-.config.patch
>> 0044-am33xx-Add-default-config.patch
>> 0073-defconfig-Update-bone-default-config.patch
>>
>> Quoted from oe_manual "The patch will be applied from the unpacked source
>> directory, ${S}".
>> Above patches create and modify defconfig file. 0002-add created it and
>> next two tweak it slightly. I double checked this by first deleting:
>> ${WORKDIR}/defconfig and ${S}/defconfig and then running:
>> bitbake -f -c unpack linux-mainline
>>
>> At this point there is ${WORKDIR}/defconfig that my layer provides.
>> Then I run:
>> bitbake -f -c patch linux-mainline
>>
>> Now there is also ${S}/defconfig.
>> Then I executed patches with those three patch files in quite a different
>> place - and that produced there defconfig file that was identical with
>> ${S}/defconfig. BTW Koen, please check who has signed off:
>>
>> https://github.com/beagleboard/meta-beagleboard/blob/master/common-bsp/recipes-kernel/linux/linux-mainline-3.8/not-capebus/0002-add-defconfig-file-to-use-as-.config.patch
>> He might be someone you know :-)
>> So, I would say OE produces ${S}/defconfig.
>>
>>>
> ${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
>
>
This is outdated information - wild quess - before I noticed how that
${S}/defconfig was really generated by those patches I explained above.
>>>
>>> As I said above, ${S}/defconfig is not used in the build.
>>>
>> Good to know
>> Thanks
>>
>>
> ___
> 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
Re: [Angstrom-devel] what file kernel configuration really uses?
28 okt 2013 kl. 09:06 skrev matti kaasinen :
> 2013/10/27 Koen Kooi
>
>> On Wed, 2013-10-23 at 14:44 +0300, matti kaasinen wrote:
>>> 2013/10/23 Khem Raj
>>>
> 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.
>
>>>
>>> What I mean above is that beaglebone folks have made those patches for
>> some
>>> reason that is not quite clear tome now considering how ${S}/defconfig
>> is
>>> produced in linux.inc.
>>
>> ${S}/defconfig is neither used nor produced by OE.
>>
>> I was wrong in that there are two patches that create ${S}/defconfig.
> Instead there are three of them:
> 0002-add-defconfig-file-to-use-as-.config.patch
> 0044-am33xx-Add-default-config.patch
> 0073-defconfig-Update-bone-default-config.patch
>
> Quoted from oe_manual "The patch will be applied from the unpacked source
> directory, ${S}".
> Above patches create and modify defconfig file. 0002-add created it and
> next two tweak it slightly. I double checked this by first deleting:
> ${WORKDIR}/defconfig and ${S}/defconfig and then running:
> bitbake -f -c unpack linux-mainline
>
> At this point there is ${WORKDIR}/defconfig that my layer provides.
> Then I run:
> bitbake -f -c patch linux-mainline
>
> Now there is also ${S}/defconfig.
> Then I executed patches with those three patch files in quite a different
> place - and that produced there defconfig file that was identical with
> ${S}/defconfig. BTW Koen, please check who has signed off:
> https://github.com/beagleboard/meta-beagleboard/blob/master/common-bsp/recipes-kernel/linux/linux-mainline-3.8/not-capebus/0002-add-defconfig-file-to-use-as-.config.patch
> He might be someone you know :-)
> So, I would say OE produces ${S}/defconfig.
But in the end, it is ignored...
It is probably a leftover...
/ulf
>
>>
${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
>>> This is outdated information - wild quess - before I noticed how that
>>> ${S}/defconfig was really generated by those patches I explained above.
>>
>> As I said above, ${S}/defconfig is not used in the build.
>>
> Good to know
> Thanks
> ___
> 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
Re: [Angstrom-devel] what file kernel configuration really uses?
There is another question, I think I mentioned it earlier also in this
chain. I have also asked it in other time as own subject. No-one seems to
have opinion about that.
Koen, you might know, if it is a "feature" misbehaviour or problem in my
set-up.
For instance when I ran those tests I did first "fetch". Then I ran
"unpack". Unpacking ran again fetch and then unpack. Then I ran "patch".
Again, at least unpack was run again and then patch. Similar behaviour
seems to happen with "configure" so that patch will be run again even
though it had been ran manually before. This feature makes paching quite
awkward as if I edit some file that has been unpacked and applied with
other patches, that will be written over when running "configure" or
"compile" to check how edits worked.
I always get two warnings when I run bitbake:
WARNING: No recipes available for:
/home/sw/cpr3/oe/sources/meta-handheld/recipes-core/udev/udev_164.bbappend
/home/sw/cpr3/oe/sources/meta-intel/meta-fri2/recipes-core/tiny-init/tiny-init.bbappend
But I suppose they are nothing to do with this issue.
So, Is this something that should happen or should I try to find set-up
problem of some kind?
Thanks,
Matti
2013/10/28 matti kaasinen
>
> 2013/10/27 Koen Kooi
>
>> On Wed, 2013-10-23 at 14:44 +0300, matti kaasinen wrote:
>> > 2013/10/23 Khem Raj
>> >
>> > > > 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.
>> > > >
>> > >
>> >
>> > What I mean above is that beaglebone folks have made those patches for
>> some
>> > reason that is not quite clear tome now considering how ${S}/defconfig
>> is
>> > produced in linux.inc.
>>
>> ${S}/defconfig is neither used nor produced by OE.
>>
>> I was wrong in that there are two patches that create ${S}/defconfig.
> Instead there are three of them:
> 0002-add-defconfig-file-to-use-as-.config.patch
> 0044-am33xx-Add-default-config.patch
> 0073-defconfig-Update-bone-default-config.patch
>
> Quoted from oe_manual "The patch will be applied from the unpacked source
> directory, ${S}".
> Above patches create and modify defconfig file. 0002-add created it and
> next two tweak it slightly. I double checked this by first deleting:
> ${WORKDIR}/defconfig and ${S}/defconfig and then running:
> bitbake -f -c unpack linux-mainline
>
> At this point there is ${WORKDIR}/defconfig that my layer provides.
> Then I run:
> bitbake -f -c patch linux-mainline
>
> Now there is also ${S}/defconfig.
> Then I executed patches with those three patch files in quite a different
> place - and that produced there defconfig file that was identical with
> ${S}/defconfig. BTW Koen, please check who has signed off:
>
> https://github.com/beagleboard/meta-beagleboard/blob/master/common-bsp/recipes-kernel/linux/linux-mainline-3.8/not-capebus/0002-add-defconfig-file-to-use-as-.config.patch
> He might be someone you know :-)
> So, I would say OE produces ${S}/defconfig.
>
> >
>> > > ${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
>> > >
>> > >
>> > This is outdated information - wild quess - before I noticed how that
>> > ${S}/defconfig was really generated by those patches I explained above.
>>
>> As I said above, ${S}/defconfig is not used in the build.
>>
> Good to know
> Thanks
>
>
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] what file kernel configuration really uses?
2013/10/27 Koen Kooi
> On Wed, 2013-10-23 at 14:44 +0300, matti kaasinen wrote:
> > 2013/10/23 Khem Raj
> >
> > > > 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.
> > > >
> > >
> >
> > What I mean above is that beaglebone folks have made those patches for
> some
> > reason that is not quite clear tome now considering how ${S}/defconfig
> is
> > produced in linux.inc.
>
> ${S}/defconfig is neither used nor produced by OE.
>
> I was wrong in that there are two patches that create ${S}/defconfig.
Instead there are three of them:
0002-add-defconfig-file-to-use-as-.config.patch
0044-am33xx-Add-default-config.patch
0073-defconfig-Update-bone-default-config.patch
Quoted from oe_manual "The patch will be applied from the unpacked source
directory, ${S}".
Above patches create and modify defconfig file. 0002-add created it and
next two tweak it slightly. I double checked this by first deleting:
${WORKDIR}/defconfig and ${S}/defconfig and then running:
bitbake -f -c unpack linux-mainline
At this point there is ${WORKDIR}/defconfig that my layer provides.
Then I run:
bitbake -f -c patch linux-mainline
Now there is also ${S}/defconfig.
Then I executed patches with those three patch files in quite a different
place - and that produced there defconfig file that was identical with
${S}/defconfig. BTW Koen, please check who has signed off:
https://github.com/beagleboard/meta-beagleboard/blob/master/common-bsp/recipes-kernel/linux/linux-mainline-3.8/not-capebus/0002-add-defconfig-file-to-use-as-.config.patch
He might be someone you know :-)
So, I would say OE produces ${S}/defconfig.
>
> > > ${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
> > >
> > >
> > This is outdated information - wild quess - before I noticed how that
> > ${S}/defconfig was really generated by those patches I explained above.
>
> As I said above, ${S}/defconfig is not used in the build.
>
Good to know
Thanks
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] what file kernel configuration really uses?
On Wed, 2013-10-23 at 14:44 +0300, matti kaasinen wrote:
> 2013/10/23 Khem Raj
>
> > > 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.
> > >
> >
>
> What I mean above is that beaglebone folks have made those patches for some
> reason that is not quite clear tome now considering how ${S}/defconfig is
> produced in linux.inc.
${S}/defconfig is neither used nor produced by OE.
>
> > ${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
> >
> >
> This is outdated information - wild quess - before I noticed how that
> ${S}/defconfig was really generated by those patches I explained above.
As I said above, ${S}/defconfig is not used in the build.
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] what file kernel configuration really uses?
Ulf,
I'm not quite sure what you mean.
I've understood that layers (read layer.conf files) are scanned through
using locations and order found in BBLAYERS variable set in bblayers.conf
file. BBPATH is initialized in bblayers.conf as ${TOPDIR}. Thereafter (my
wild guess) BBPATH is appended (or prepended) with values given in the the
layer.conf files. I switched to prepending and it did not help this issue.
I have set my layer as the first instance in BBLAYERS variable whereas
meta-beagleboard/common-bsp is somewhere in the middle. My layer is using
prepending when assigning in BBPATH (should be the first instance also in
BBPATH) whereas meta-beagleboard/common-bsp uses appending. Therefore, my
layer should be handled before meta-beagleboard/common-bsp, should it not?
I may have understood this all wrong, though.
Regards,
Matti
2013/10/23 Ulf Samuelsson
> You are looking in the wrong file.
> In Angstrom, you need to change BBPATH in setup-scripts/conf/bblayers.conf
> Not in the layer.conf in your own layer.
>
> Best Regards
> Ulf Samuelsson
> u...@emagii.com
>
> 23 okt 2013 kl. 14:24 skrev matti kaasinen :
>
> > 2013/10/23 matti kaasinen
> >
> >> 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.
> >>
> >>
> > It did not help chnging BBPATH in layer.conf
> > It used to be
> > BBPATH .= ":${LAYERDIR}"
> > and I changed it to:
> > BBPATH =. "${LAYERDIR}:"
> >
> > It still fetches beaglebone's defconfig.
> >
> > Should I change my bbappend file instad not using FILESEXTRAPATHS_prepend
> > but using FILESPATH_prepend instead?
> > Do FILESPATH have precedence over FILESEXTRAPATHS?
> >
> > Cheers,
> > Matti
> > ___
> > 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
>
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] what file kernel configuration really uses?
You are looking in the wrong file.
In Angstrom, you need to change BBPATH in setup-scripts/conf/bblayers.conf
Not in the layer.conf in your own layer.
Best Regards
Ulf Samuelsson
u...@emagii.com
23 okt 2013 kl. 14:24 skrev matti kaasinen :
> 2013/10/23 matti kaasinen
>
>> 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.
>>
>>
> It did not help chnging BBPATH in layer.conf
> It used to be
> BBPATH .= ":${LAYERDIR}"
> and I changed it to:
> BBPATH =. "${LAYERDIR}:"
>
> It still fetches beaglebone's defconfig.
>
> Should I change my bbappend file instad not using FILESEXTRAPATHS_prepend
> but using FILESPATH_prepend instead?
> Do FILESPATH have precedence over FILESEXTRAPATHS?
>
> Cheers,
> Matti
> ___
> 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
Re: [Angstrom-devel] what file kernel configuration really uses?
2013/10/23 matti kaasinen
> 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.
>>
>>
> It did not help chnging BBPATH in layer.conf
> It used to be
> BBPATH .= ":${LAYERDIR}"
> and I changed it to:
> BBPATH =. "${LAYERDIR}:"
>
> It still fetches beaglebone's defconfig.
>
> Should I change my bbappend file instad not using FILESEXTRAPATHS_prepend
> but using FILESPATH_prepend instead?
> Do FILESPATH have precedence over FILESEXTRAPATHS?
>
I replaced
FILESEXTRAPATHS_prepend := "${THISDIR}/linux-mainline-3.8:"
with
FILESPATH_prepend := "${THISDIR}/linux-mainline-3.8:"
in my bbappend file and now ${WORKDIR}/defconfig is coming from my metadata.
Now this looks mych better!
Cheers,
Matti
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] what file kernel configuration really uses?
2013/10/23 matti kaasinen
> 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.
>
>
It did not help chnging BBPATH in layer.conf
It used to be
BBPATH .= ":${LAYERDIR}"
and I changed it to:
BBPATH =. "${LAYERDIR}:"
It still fetches beaglebone's defconfig.
Should I change my bbappend file instad not using FILESEXTRAPATHS_prepend
but using FILESPATH_prepend instead?
Do FILESPATH have precedence over FILESEXTRAPATHS?
Cheers,
Matti
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] what file kernel configuration really uses?
2013/10/23 Khem Raj
> > 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.
> >
>
What I mean above is that beaglebone folks have made those patches for some
reason that is not quite clear tome now considering how ${S}/defconfig is
produced in linux.inc.
> ${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
>
>
This is outdated information - wild quess - before I noticed how that
${S}/defconfig was really generated by those patches I explained above.
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, I'll check this
Matti
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] what file kernel configuration really uses?
On Wed, Oct 23, 2013 at 3:07 AM, matti kaasinen
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
>
>> 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
>>>
>>> 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 :
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:
> B
Re: [Angstrom-devel] what file kernel configuration really uses?
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.
Providing defconfig directly did not work - most likely it was written over
by the patching the seems creating the ${WORKDIR}/defconfig
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.
Thanks,
Matti
2013/10/22 Ulf Samuelsson
> 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
>>
>> 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 :
>>>
>>> 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 = ":"
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
http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**
>>> angstrom-distro-devel
Re: [Angstrom-devel] what file kernel configuration really uses?
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
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 :
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 = ":"
meta-angstrom =
"angstrom-v2012.12-yocto1.3:b7f8207b94d9a0ece73ad212a193cb2c95bd17ee"
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
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
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] what file kernel configuration really uses?
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 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 > 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 : > > > 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 = ":" > > meta-angstrom = > > "angstrom-v2012.12-yocto1.3:b7f8207b94d9a0ece73ad212a193cb2c95bd17ee" > > > > 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 > > > 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
Re: [Angstrom-devel] what file kernel configuration really uses?
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 : > 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 = ":" > meta-angstrom = > "angstrom-v2012.12-yocto1.3:b7f8207b94d9a0ece73ad212a193cb2c95bd17ee" > > 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 > 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-devel] what file kernel configuration really uses?
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 = ":" meta-angstrom = "angstrom-v2012.12-yocto1.3:b7f8207b94d9a0ece73ad212a193cb2c95bd17ee" 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 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
