[yocto] kernel rebuild and bitbake -c menuconfig

[Bruce Ashfield]

On 12-05-11 08:51 AM, Frans Meulenbroeks wrote:
> 2012/5/11 Bruce Ashfield<bruce.ashfield at 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