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: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

Reply via email to