Hi Khem--
Thanks for the info on the rm_work thing--I'll keep that in mind as I go
forward. I would have tried it now except I ran into so many other
strange things that I ended up removing the entire build directory and
starting over! When I rebuilt everything I still ran into the same
kernel strange-ness, though. Here are the steps I took:
1) ./oebb.sh update
2) bitbake systemd-git
3) bitbake virtual/kernel -c menuconfig
4) bitbake virtual/kernel -c build
5) bitbake virtual/kernel -c compile -f
6) bitbake virtual/kernel -c build
7) bitbake virtual/kernel -c install
8) bitbake systemd-gnome-image
9) bitbake virtual/kernel -c deploy
10) bitbake virtual/kernel -c deploy -f
In step 2 I just wanted to get all the native stuff built and a few
basics for the target. In the process it did build a kernel object. In
step 3 I applied my own custom settings (trying to get a smaller, faster
kernel). I had to force the compile, hence steps 4/5/6.
When I did step 7 I think that's where it did the compile_kernelmodules
and finished up the building (I don't remember but I don't think step 6
did anything). At this point I figured my new kernel was "the" kernel
that would be used for subsequent builds. Nope.
When I went to build the full systemd-gnome-image for step 8 it did not
use my "new" kernel. Instead it resurrected the one from step 2 and
used that. Bitbake did not remove the
work/beagleboard/linux-mainline... directories (thankfully) so I still
had my work. Still, I don't understand why it selected the "old" kernel
and modules instead of the "new".
Once the full image was built I tried the deploy command to see if it
would at least put a uImage and modules file in the
deploy/images/beagleboard directory. The regular deploy in step 9
didn't do anything, but forcing it in step 10 did.
So in the end I was able to more or less get to where I wanted, but I
think it should have automatically incorporated my kernel with changes
instead of having all this hassle. Is my thinking way off or was I
supposed to do another step somewhere?
Also, I was using the steps from the following link to do my work:
http://hipstercircuits.com/?p=245
Note that those steps are for beaglebone and on Angstrom 2012.05/yocto
1.2, but I think the basic procedure still applies. Note also the
comments as further suggestions/updates are mentioned there. One thing
in particular is the idea that "install" is to be used instead of
"deploy" but I don't know much about that.
Anyway, any and all advice you can provide is appreciated! Thanks!
On 2/26/2013 2:22 PM, Khem Raj wrote:
On Tue, Feb 26, 2013 at 11:07 AM, Peter Kurrasch <gtin...@hotmail.com> wrote:
I'm using angstrom 2012.12 w/ yocto 1.3 (for Beagleboard-xM) and I keep
running into this frustrating problem as I'm making kernel updates and
rebuild my system image.
Basically I make my kernel updates, rebuild it, etc. and get a suitable
uImage that works. Then I go build anything else
OK what is this you did here. Concrete examples will help understand the issue
better.
and the first thing
bitbake does is run the SetScene scripts that wipe out my kernel updates and
the images. In fact in the deploy/images/beagleboard directory not only has
my uImage removed but 4 old ones appear in it's place--from Feb 8th! I
can't figure out where those old things are squirreled away nor how to get
rid of them.
It could be because rm_work is enabled in local.conf. You could experiment
by disabling that.
_______________________________________________
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
