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 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.orgAngstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**
angstrom-distro-develhttp://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
__**_
Angstrom-distro-devel mailing list
Angstrom-distro-devel@**linuxtogo.orgAngstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**
Re: [Angstrom-devel] what file kernel configuration really uses?
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 =
Re: [Angstrom-devel] what file kernel configuration really uses?
2013/10/23 Khem Raj raj.k...@gmail.com
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?
2013/10/23 matti kaasinen matti.kaasi...@gmail.com
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?
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 matti.kaasi...@gmail.com:
2013/10/23 matti kaasinen matti.kaasi...@gmail.com
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] v2013.06 and v2013.12 architecture change for ARMv7A machines
On 10/20/2013 09:04 PM, Koen Kooi wrote:
Then I noticed that the 'genericarmv7a' machine in meta-linaro set
the DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set
that variable, but that's a different bug. It turns out that using
that tune we can have a single feed again for all armv7a machines.
Hi,
just for clarification, I'm not sure where to set it if not in the
MACHINE config without modifying meta-angstrom.
I've seen you added MACHINE specific DEFAULTTUNEs based on the currently
supported boards.
Basically the result should be (IMHO):
if MACHINE is a armv7a based and DISTRO is angstrom, then
DEFAULTTUNE = armv7athf-neon
Would it be possible to add those definitions based on SOC_FAMILY:
DEFAULTTUNE_ti33x and DEFAULTTUNE_omap3?
As of now, when I add a new MACHINE=machfoo based on ti33x.inc from
meta-ti, I end up with a DEFAULTTUNE=armv7a-neon instead of the new one,
as the board is not known in meta-angstrom.
I added
DEFAULTTUNE_machfoo = ${DEFAULTTUNE_genericarmv7a}
to the machfoo.conf which is discouraged, if I understand you correctly.
Maybe I'm just missing the obvious safe way?
Thx
Björn
--
Björn Krombholz
pironex GmbH -- http://www.pironex.de
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
Best Regards
Ulf Samuelsson
u...@emagii.com
+46 (722) 427 437
23 okt 2013 kl. 18:30 skrev Björn Krombholz pir...@gmail.com:
On 10/20/2013 09:04 PM, Koen Kooi wrote:
Then I noticed that the 'genericarmv7a' machine in meta-linaro set
the DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set
that variable, but that's a different bug. It turns out that using
that tune we can have a single feed again for all armv7a machines.
Hi,
just for clarification, I'm not sure where to set it if not in the MACHINE
config without modifying meta-angstrom.
I've seen you added MACHINE specific DEFAULTTUNEs based on the currently
supported boards.
Basically the result should be (IMHO):
if MACHINE is a armv7a based and DISTRO is angstrom, then
DEFAULTTUNE = armv7athf-neon
Since not all arm7va have neon. it is optional on Cortex-A5
and there are already arm7a chips without neon round,
so this is not a good idea.
Would it be possible to add those definitions based on SOC_FAMILY:
DEFAULTTUNE_ti33x and DEFAULTTUNE_omap3?
Better.
As of now, when I add a new MACHINE=machfoo based on ti33x.inc from meta-ti,
I end up with a DEFAULTTUNE=armv7a-neon instead of the new one, as the board
is not known in meta-angstrom.
I added
DEFAULTTUNE_machfoo = ${DEFAULTTUNE_genericarmv7a}
to the machfoo.conf which is discouraged, if I understand you correctly.
Maybe I'm just missing the obvious safe way?
Thx
Björn
--
Björn Krombholz
pironex GmbH -- http://www.pironex.de
___
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] Looking for an Angstrom and bitbake expert to consult / contract
Hello. We are looking at using Angstrom and bitbake. There are several areas where we could use an expert that could both consult on questions and approaches as well as help implement some of the customization that we may need to ship product. This might start out as a several hour contract, phone or email consultation, and extend to a handful of weeks. We are located in the Boston area but remote is fine. If you might be interested please send me a short email letting me know what your rate would be, a little about your background and some way to get in touch. Chris ___ 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 angstrom-...@emagii.com
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 matti.kaasi...@gmail.com:
2013/10/23 matti kaasinen matti.kaasi...@gmail.com
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
