2013/10/27 Koen Kooi k...@dominion.thruhere.net
On Wed, 2013-10-23 at 14:44 +0300, matti kaasinen wrote:
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
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
28 okt 2013 kl. 09:06 skrev matti kaasinen matti.kaasi...@gmail.com:
2013/10/27 Koen Kooi k...@dominion.thruhere.net
On Wed, 2013-10-23 at 14:44 +0300, matti kaasinen wrote:
2013/10/23 Khem Raj raj.k...@gmail.com
Hi Ulf,
Yes, linux.inc seems doing the job as you told - this clears a
I have noticed this as well and it is highly irritating,
Best Regards
Ulf Samuelsson
28 okt 2013 kl. 09:23 skrev matti kaasinen matti.kaasi...@gmail.com:
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
On Wed, 2013-10-23 at 14:44 +0300, matti kaasinen wrote:
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
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:
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.
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
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
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
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
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,
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
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
14 matches
Mail list logo
