All of lore.kernel.org
 help / color / mirror / Atom feed
* How to build a kernel using menuconfig
@ 2011-09-26 13:45 Gary Thomas
  2011-09-28  3:45 ` Darren Hart
  0 siblings, 1 reply; 6+ messages in thread
From: Gary Thomas @ 2011-09-26 13:45 UTC (permalink / raw)
  To: Poky Project

I'm working with a recent Poky checkout:
   meta-yocto        = "master:7a0cbe6b0e5185aebabedc515b427994bc2a15dc"

I used to be able to do this:
   % bitbake <some-image>
This step builds everything, including the kernel
   % bitbake virtual/kernel -c menuconfig
Adjust some settings
   % bitbake virtual/kernel -c compile -f
   % bitbake virtual/kernel
Rebuild my image with the new kernel included
   % bitbake <some-image>

In the past, this would let me adjust some kernel settings, e.g. add a new
module, then rebuild it and later add this to an image.  Sadly, when I run
through these steps with the current master, the new kernel gets compiled
(because I used -f), but not packaged.

The only thing I've done differently, save updating master, is my build
today includes
   INHERIT += "rm_work"

Am I missing something?

How can I build the kernel and make these in-tree adjustments like I used to?
I do this to figure out what kernel settings to set/save for my final packaging.

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: How to build a kernel using menuconfig
  2011-09-26 13:45 How to build a kernel using menuconfig Gary Thomas
@ 2011-09-28  3:45 ` Darren Hart
  2011-09-28 11:33   ` Gary Thomas
  0 siblings, 1 reply; 6+ messages in thread
From: Darren Hart @ 2011-09-28  3:45 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Poky Project



On 09/26/2011 06:45 AM, Gary Thomas wrote:
> I'm working with a recent Poky checkout:
>    meta-yocto        = "master:7a0cbe6b0e5185aebabedc515b427994bc2a15dc"
> 
> I used to be able to do this:
>    % bitbake <some-image>
> This step builds everything, including the kernel
>    % bitbake virtual/kernel -c menuconfig
> Adjust some settings
>    % bitbake virtual/kernel -c compile -f
>    % bitbake virtual/kernel
> Rebuild my image with the new kernel included
>    % bitbake <some-image>
> 
> In the past, this would let me adjust some kernel settings, e.g. add a new
> module, then rebuild it and later add this to an image.  Sadly, when I run
> through these steps with the current master, the new kernel gets compiled
> (because I used -f), but not packaged.
> 
> The only thing I've done differently, save updating master, is my build
> today includes
>    INHERIT += "rm_work"
> 
> Am I missing something?
> 
> How can I build the kernel and make these in-tree adjustments like I used to?
> I do this to figure out what kernel settings to set/save for my final packaging.


Yeah, this is standard kernel devel workflow. I typically use the kernel
recipe name directly, but otherwise my process is the same. What happens
now when you run "bitbake virtual/kernel" after the compile -f ?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: How to build a kernel using menuconfig
  2011-09-28  3:45 ` Darren Hart
@ 2011-09-28 11:33   ` Gary Thomas
  2011-09-28 13:15     ` Richard Purdie
  0 siblings, 1 reply; 6+ messages in thread
From: Gary Thomas @ 2011-09-28 11:33 UTC (permalink / raw)
  To: Darren Hart; +Cc: Poky Project

On 2011-09-27 21:45, Darren Hart wrote:
>
>
> On 09/26/2011 06:45 AM, Gary Thomas wrote:
>> I'm working with a recent Poky checkout:
>>     meta-yocto        = "master:7a0cbe6b0e5185aebabedc515b427994bc2a15dc"
>>
>> I used to be able to do this:
>>     % bitbake<some-image>
>> This step builds everything, including the kernel
>>     % bitbake virtual/kernel -c menuconfig
>> Adjust some settings
>>     % bitbake virtual/kernel -c compile -f
>>     % bitbake virtual/kernel
>> Rebuild my image with the new kernel included
>>     % bitbake<some-image>
>>
>> In the past, this would let me adjust some kernel settings, e.g. add a new
>> module, then rebuild it and later add this to an image.  Sadly, when I run
>> through these steps with the current master, the new kernel gets compiled
>> (because I used -f), but not packaged.
>>
>> The only thing I've done differently, save updating master, is my build
>> today includes
>>     INHERIT += "rm_work"
>>
>> Am I missing something?
>>
>> How can I build the kernel and make these in-tree adjustments like I used to?
>> I do this to figure out what kernel settings to set/save for my final packaging.
>
>
> Yeah, this is standard kernel devel workflow. I typically use the kernel
> recipe name directly, but otherwise my process is the same. What happens
> now when you run "bitbake virtual/kernel" after the compile -f ?
>

As indicated above, nothing.  If I remove rm_work from my configuration
and then rebuild the kernel, it works as expected.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: How to build a kernel using menuconfig
  2011-09-28 11:33   ` Gary Thomas
@ 2011-09-28 13:15     ` Richard Purdie
  2011-09-28 13:35       ` Gary Thomas
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Purdie @ 2011-09-28 13:15 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Darren Hart, Poky Project

On Wed, 2011-09-28 at 05:33 -0600, Gary Thomas wrote:
> On 2011-09-27 21:45, Darren Hart wrote:
> >
> >
> > On 09/26/2011 06:45 AM, Gary Thomas wrote:
> >> I'm working with a recent Poky checkout:
> >>     meta-yocto        = "master:7a0cbe6b0e5185aebabedc515b427994bc2a15dc"
> >>
> >> I used to be able to do this:
> >>     % bitbake<some-image>
> >> This step builds everything, including the kernel
> >>     % bitbake virtual/kernel -c menuconfig
> >> Adjust some settings
> >>     % bitbake virtual/kernel -c compile -f
> >>     % bitbake virtual/kernel
> >> Rebuild my image with the new kernel included
> >>     % bitbake<some-image>
> >>
> >> In the past, this would let me adjust some kernel settings, e.g. add a new
> >> module, then rebuild it and later add this to an image.  Sadly, when I run
> >> through these steps with the current master, the new kernel gets compiled
> >> (because I used -f), but not packaged.
> >>
> >> The only thing I've done differently, save updating master, is my build
> >> today includes
> >>     INHERIT += "rm_work"
> >>
> >> Am I missing something?
> >>
> >> How can I build the kernel and make these in-tree adjustments like I used to?
> >> I do this to figure out what kernel settings to set/save for my final packaging.
> >
> >
> > Yeah, this is standard kernel devel workflow. I typically use the kernel
> > recipe name directly, but otherwise my process is the same. What happens
> > now when you run "bitbake virtual/kernel" after the compile -f ?
> >
> 
> As indicated above, nothing.  If I remove rm_work from my configuration
> and then rebuild the kernel, it works as expected.

It sounds like there is a bad interaction between rm_work and this set
of steps. I can kind of see why, rm_work promotes the stamp files to
setscene ones (so the same as if a sstate build was made). Nothing in
the above steps would actually remove the setscene stamps so bitbake
sees them and assumes everything is still valid.

If you did a bitbake -c package -f virtual/kernel then I suspect it
would actually sort itself out. Off the top of my head I can't see a way
to fix this in any straightforward way :/.

Cheers,

Richard




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: How to build a kernel using menuconfig
  2011-09-28 13:15     ` Richard Purdie
@ 2011-09-28 13:35       ` Gary Thomas
  2011-09-28 23:58         ` Gary Thomas
  0 siblings, 1 reply; 6+ messages in thread
From: Gary Thomas @ 2011-09-28 13:35 UTC (permalink / raw)
  To: Richard Purdie; +Cc: Darren Hart, Poky Project

On 2011-09-28 07:15, Richard Purdie wrote:
> On Wed, 2011-09-28 at 05:33 -0600, Gary Thomas wrote:
>> On 2011-09-27 21:45, Darren Hart wrote:
>>>
>>>
>>> On 09/26/2011 06:45 AM, Gary Thomas wrote:
>>>> I'm working with a recent Poky checkout:
>>>>      meta-yocto        = "master:7a0cbe6b0e5185aebabedc515b427994bc2a15dc"
>>>>
>>>> I used to be able to do this:
>>>>      % bitbake<some-image>
>>>> This step builds everything, including the kernel
>>>>      % bitbake virtual/kernel -c menuconfig
>>>> Adjust some settings
>>>>      % bitbake virtual/kernel -c compile -f
>>>>      % bitbake virtual/kernel
>>>> Rebuild my image with the new kernel included
>>>>      % bitbake<some-image>
>>>>
>>>> In the past, this would let me adjust some kernel settings, e.g. add a new
>>>> module, then rebuild it and later add this to an image.  Sadly, when I run
>>>> through these steps with the current master, the new kernel gets compiled
>>>> (because I used -f), but not packaged.
>>>>
>>>> The only thing I've done differently, save updating master, is my build
>>>> today includes
>>>>      INHERIT += "rm_work"
>>>>
>>>> Am I missing something?
>>>>
>>>> How can I build the kernel and make these in-tree adjustments like I used to?
>>>> I do this to figure out what kernel settings to set/save for my final packaging.
>>>
>>>
>>> Yeah, this is standard kernel devel workflow. I typically use the kernel
>>> recipe name directly, but otherwise my process is the same. What happens
>>> now when you run "bitbake virtual/kernel" after the compile -f ?
>>>
>>
>> As indicated above, nothing.  If I remove rm_work from my configuration
>> and then rebuild the kernel, it works as expected.
>
> It sounds like there is a bad interaction between rm_work and this set
> of steps. I can kind of see why, rm_work promotes the stamp files to
> setscene ones (so the same as if a sstate build was made). Nothing in
> the above steps would actually remove the setscene stamps so bitbake
> sees them and assumes everything is still valid.
>
> If you did a bitbake -c package -f virtual/kernel then I suspect it
> would actually sort itself out. Off the top of my head I can't see a way
> to fix this in any straightforward way :/.

My inclination is to just not allow rm_work for kernel recipes.  Perhaps
it's possible to filter out rm_work for this recipe like this?
   INHERIT := "${@oe_filter_out('rm_work', '${INHERIT}', d)}"
Note: I've not tried it, just a thought.

Thanks for your time

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: How to build a kernel using menuconfig
  2011-09-28 13:35       ` Gary Thomas
@ 2011-09-28 23:58         ` Gary Thomas
  0 siblings, 0 replies; 6+ messages in thread
From: Gary Thomas @ 2011-09-28 23:58 UTC (permalink / raw)
  To: Richard Purdie; +Cc: Darren Hart, Poky Project

On 2011-09-28 07:35, Gary Thomas wrote:
> On 2011-09-28 07:15, Richard Purdie wrote:
>> On Wed, 2011-09-28 at 05:33 -0600, Gary Thomas wrote:
>>> On 2011-09-27 21:45, Darren Hart wrote:
>>>>
>>>>
>>>> On 09/26/2011 06:45 AM, Gary Thomas wrote:
>>>>> I'm working with a recent Poky checkout:
>>>>> meta-yocto = "master:7a0cbe6b0e5185aebabedc515b427994bc2a15dc"
>>>>>
>>>>> I used to be able to do this:
>>>>> % bitbake<some-image>
>>>>> This step builds everything, including the kernel
>>>>> % bitbake virtual/kernel -c menuconfig
>>>>> Adjust some settings
>>>>> % bitbake virtual/kernel -c compile -f
>>>>> % bitbake virtual/kernel
>>>>> Rebuild my image with the new kernel included
>>>>> % bitbake<some-image>
>>>>>
>>>>> In the past, this would let me adjust some kernel settings, e.g. add a new
>>>>> module, then rebuild it and later add this to an image. Sadly, when I run
>>>>> through these steps with the current master, the new kernel gets compiled
>>>>> (because I used -f), but not packaged.
>>>>>
>>>>> The only thing I've done differently, save updating master, is my build
>>>>> today includes
>>>>> INHERIT += "rm_work"
>>>>>
>>>>> Am I missing something?
>>>>>
>>>>> How can I build the kernel and make these in-tree adjustments like I used to?
>>>>> I do this to figure out what kernel settings to set/save for my final packaging.
>>>>
>>>>
>>>> Yeah, this is standard kernel devel workflow. I typically use the kernel
>>>> recipe name directly, but otherwise my process is the same. What happens
>>>> now when you run "bitbake virtual/kernel" after the compile -f ?
>>>>
>>>
>>> As indicated above, nothing. If I remove rm_work from my configuration
>>> and then rebuild the kernel, it works as expected.
>>
>> It sounds like there is a bad interaction between rm_work and this set
>> of steps. I can kind of see why, rm_work promotes the stamp files to
>> setscene ones (so the same as if a sstate build was made). Nothing in
>> the above steps would actually remove the setscene stamps so bitbake
>> sees them and assumes everything is still valid.
>>
>> If you did a bitbake -c package -f virtual/kernel then I suspect it
>> would actually sort itself out. Off the top of my head I can't see a way
>> to fix this in any straightforward way :/.
>
> My inclination is to just not allow rm_work for kernel recipes. Perhaps
> it's possible to filter out rm_work for this recipe like this?
> INHERIT := "${@oe_filter_out('rm_work', '${INHERIT}', d)}"
> Note: I've not tried it, just a thought.

Sadly, this doesn't work.  For now, I'll just note that rm_work is
incompatible with kernel fiddling :-(

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-09-28 23:58 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-26 13:45 How to build a kernel using menuconfig Gary Thomas
2011-09-28  3:45 ` Darren Hart
2011-09-28 11:33   ` Gary Thomas
2011-09-28 13:15     ` Richard Purdie
2011-09-28 13:35       ` Gary Thomas
2011-09-28 23:58         ` Gary Thomas

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.