On 12-05-11 08:51 AM, Frans Meulenbroeks wrote:
2012/5/11 Bruce Ashfield<bruce.ashfi...@windriver.com>:
On 12-05-11 03:07 AM, Frans Meulenbroeks wrote:

Hi,

I'm wondering how to do a kernel rebuild after doing changing the .config
using
bitbake -c menuconfig virtual/kernel
I've tried forcing a recompile using:
bitbake -ccompile -f virtual/kernel
that indeed rebuilds the kernel
However if I then do a bitbake virtual/kernel this does not result in
an image in my deploy dir.

system info
host: ubuntu 12.04
denzil 7.0 software (from tarball)
target: ppc (actually for my own board but I did not do weird things
in my bsp, like adding extra tasks.

It seems the vmlinux.bin.gz is still generated but the uImage is not
(which can also be seen from the log below where do_install is not
ran.
Additional proof:
f5ad9f2b30047a8d3493a1a2880a-r1.40$ ls -l ./image/kernel/uImage
./linux-syrcxx-standard-build/vmlinux.bin.gz
-rw-r--r-- 1 frans frans 1609509 2012-05-10 10:19 ./image/kernel/uImage
-rwxr-xr-x 1 frans frans 1611499 2012-05-11 08:52
./linux-syrcxx-standard-build/vmlinux.bin.gz
This si from after I ran the bitbake commands below.

What is going wrong here?


You are likely hitting this bug:

  https://bugzilla.yoctoproject.org/show_bug.cgi?id=2256

It's a known issue that is being worked on for 1.3, but the bugzilla has
workarounds that youl can use in the meantime.

Cheers,

Bruce

Bruce,

Thanks for the reference.
I am indeed seeing that bug.

What I did was the solution of Darren that was listed in comment5, but
that did not work for me.
I was unaware of the cleansstate task.

Actually thinking of it, if in the flow:
$ bitbake virtual/kernel -c cleansstate
$ bitbake virtual/kernel -c menuconfig
$ bitbake virtual/kernel -c compile -f; bitbake virtual/kernel
the first two steps can be exchanged (so first menuconfig then
cleansstate, then menuconfig could force the cleansstate to run

(or menuconfig could run cleanstate befure doing the actual menuconfig work)

Hopefully we'll end up with a flag that can just indicate that sstate
shouldn't be used for a particular package after a certain trigger has
been hit .. or something like that :)

But indeed, we could automatically trigger some sstate cleaning as well
as an option.

Glad to hear that you are around the issue now,

Bruce


Best regards, Frans

_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to