workflow - kernel config

workflow - kernel config

[Robert Berger]

Hi,

I'm playing with poky-edison-6.0 and the default 2.6.37.6 kernel on a
beagle board with core-image-sato-sdk.

Interestingly enough there is user space support e.g. for oprofile, but
oprofile is not configured in the kernel.

The same for lacencytop and powertop,...

So I was wondering what's the preferred workflow to start with the
"yocto-default" kernel config and add kernel configuration options
afterwards.

What's I've tried so far is:

bitbake virtual/kernel -c clean
bitbake virtual/kernel -c configure
bitbake virtual/kernel -c menuconfig
bitbake virtual/kernel -c compile
bitbake virtual/kernel -c deploy

Once I'll have a kernel config I'm happy with I would like to use a
config file instead of menuconfig.

Please advise,

Regards,

Robert
...WANTED: Schroedinger's Cat. Dead or Alive.

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

Re: workflow - kernel config

[Robert Berger]

This did not work:

root@beagleboard:~# opcontrol --start
FATAL: Module oprofile not found.
FATAL: Module oprofile not found.
Kernel doesn't support oprofile

Please advise,

Robert
...Before God we are all equally wise - and equally foolish. - Albert
Einstein

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

Re: workflow - kernel config

[Bruce Ashfield]

On Fri, Nov 4, 2011 at 1:23 PM, Robert Berger
<gmane@reliableembeddedsystems.com> wrote:
> Hi,
>
> I'm playing with poky-edison-6.0 and the default 2.6.37.6 kernel on a
> beagle board with core-image-sato-sdk.
>
> Interestingly enough there is user space support e.g. for oprofile, but
> oprofile is not configured in the kernel.
>
> The same for lacencytop and powertop,...

We have feature descriptions for all of the above as components in the
linux-yocto
kernel repository, but they do need to be turned on and tested on a per board
basis.

We can trigger kernel options based on userspace packages being enabled or
disabled, but that still wouldn't be a guarantee that they'd work. The
options that
are within the tree are a documentation of what has actually been tested.

The 2.6.37 tree was a transition point,and we've continued standardizing the
options and feature set in the later kernels. For yocto 1.2 we'll have a better
defined and consistent set of feature blocks. It's a building process
and we move
forward.

As others will point out there are other/deeper beagle board BSPs and layers
(i.e. meta-texasinstruments) that likely already have support for these options\
(but I haven't checked recently), so that's an avenue to explore as well.

>
> So I was wondering what's the preferred workflow to start with the
> "yocto-default" kernel config and add kernel configuration options
> afterwards.
>
> What's I've tried so far is:
>
> bitbake virtual/kernel -c clean
> bitbake virtual/kernel -c configure
> bitbake virtual/kernel -c menuconfig
> bitbake virtual/kernel -c compile
> bitbake virtual/kernel -c deploy

This is one flow that will work to make changes to the default kernel, and
test them on a board. I use something like:

 bitbake -f -c configure linux-yocto
 bitbake -f -c menuconfig
 bitbake -c linux-yocto

after I've done an initial build/configure phase if I'm updating options.
But that's likely not the most efficient workflow either (I've got liberal
use of -f in there, since I'm a bit paranoid).

>
> Once I'll have a kernel config I'm happy with I would like to use a
> config file instead of menuconfig.

If you take the set of kernel options you are interested in, and put them
in a config fragment. i.e. my_options.cfg, you can simply add this to
the SRC_URI and those options will be applied to the kernel after all the
default ones have been applied.

Hope that helps a bit.

Bruce

>
> Please advise,
>
> Regards,
>
> Robert
> ...WANTED: Schroedinger's Cat. Dead or Alive.
>
> My public pgp key is available at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
>
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: workflow - kernel config

[Robert Berger]

Hi Bruce,

On 11/04/2011 09:15 PM, Bruce Ashfield wrote:
> 
> This is one flow that will work to make changes to the default kernel, and
> test them on a board. I use something like:
> 
>  bitbake -f -c configure linux-yocto
>  bitbake -f -c menuconfig
>  bitbake -c linux-yocto
> 
> after I've done an initial build/configure phase if I'm updating options.
> But that's likely not the most efficient workflow either (I've got liberal
> use of -f in there, since I'm a bit paranoid).
> 

This does not seem to work either - menuconfig is not being invoked:

rber@yocto-1:~/projects/yocto/yocto_for_trainer/sandbox_work$
./03.05-configure-build-poky-kernel.sh

### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    meta-toolchain-sdk
    adt-installer
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

----->
make sure INHERIT += "rm_work" is commented out
kernel fiddling will not work with it
press <ENTER> to go on
<-----

Loading cache: 100%
|########################################################################################|
ETA:  00:00:00
Loaded 1036 entries from dependency cache.

OE Build Configuration:
BB_VERSION        = "1.13.3"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "beagleboard"
DISTRO            = "poky"
DISTRO_VERSION    = "1.1"
TUNE_FEATURES     = "armv7a vfp neon cortexa8"
TARGET_FPU        = "vfp-neon"
meta
meta-yocto        =
"edison-6.0_LOCAL:1924f52cc894d4dd6b9d9c1a2248b32fc0a24c8c"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 299 of 299 (ID: 6,
/work/rber/poky/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb,
do_configure)
NOTE: package
linux-yocto-2.6.37+git1+aeea99683c7283f1f3320bf2ee7085ee252d4e7e_1+3ddb22772862a8223640fa97580569924f51bddc-r21:
task do_configure: Started
NOTE: package
linux-yocto-2.6.37+git1+aeea99683c7283f1f3320bf2ee7085ee252d4e7e_1+3ddb22772862a8223640fa97580569924f51bddc-r21:
task do_configure: Succeeded
NOTE: Tasks Summary: Attempted 299 tasks of which 298 didn't need to be
rerun and 0 failed.
Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake
--help' for usage information.
Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake
--help' for usage information.
rber@yocto-1:~/projects/yocto/yocto_for_trainer/sandbox_work$


Regards,

Robert..."The wonderful thing about standards is that there are so many
of them to choose from." - (Amazing) Grace Murray Hopper, as quoted in
the Unix Haters Handbook, p.10

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

Re: workflow - kernel config

[Bruce Ashfield]

On Sat, Nov 5, 2011 at 2:34 AM, Robert Berger
<gmane@reliableembeddedsystems.com> wrote:
> Hi Bruce,
>
> On 11/04/2011 09:15 PM, Bruce Ashfield wrote:
>>
>> This is one flow that will work to make changes to the default kernel, and
>> test them on a board. I use something like:
>>
>>  bitbake -f -c configure linux-yocto
>>  bitbake -f -c menuconfig
>>  bitbake -c linux-yocto
>>
>> after I've done an initial build/configure phase if I'm updating options.
>> But that's likely not the most efficient workflow either (I've got liberal
>> use of -f in there, since I'm a bit paranoid).
>>
>
> This does not seem to work either - menuconfig is not being invoked:
>
> rber@yocto-1:~/projects/yocto/yocto_for_trainer/sandbox_work$
> ./03.05-configure-build-poky-kernel.sh
>
> ### Shell environment set up for builds. ###
>
> You can now run 'bitbake <target>'
>
> Common targets are:
>    core-image-minimal
>    core-image-sato
>    meta-toolchain
>    meta-toolchain-sdk
>    adt-installer
>    meta-ide-support
>
> You can also run generated qemu images with a command like 'runqemu qemux86'
>
> ----->
> make sure INHERIT += "rm_work" is commented out
> kernel fiddling will not work with it
> press <ENTER> to go on
> <-----
>
> Loading cache: 100%
> |########################################################################################|
> ETA:  00:00:00
> Loaded 1036 entries from dependency cache.
>
> OE Build Configuration:
> BB_VERSION        = "1.13.3"
> TARGET_ARCH       = "arm"
> TARGET_OS         = "linux-gnueabi"
> MACHINE           = "beagleboard"
> DISTRO            = "poky"
> DISTRO_VERSION    = "1.1"
> TUNE_FEATURES     = "armv7a vfp neon cortexa8"
> TARGET_FPU        = "vfp-neon"
> meta
> meta-yocto        =
> "edison-6.0_LOCAL:1924f52cc894d4dd6b9d9c1a2248b32fc0a24c8c"
>
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Running task 299 of 299 (ID: 6,
> /work/rber/poky/meta/recipes-kernel/linux/linux-yocto_2.6.37.bb,
> do_configure)
> NOTE: package
> linux-yocto-2.6.37+git1+aeea99683c7283f1f3320bf2ee7085ee252d4e7e_1+3ddb22772862a8223640fa97580569924f51bddc-r21:
> task do_configure: Started
> NOTE: package
> linux-yocto-2.6.37+git1+aeea99683c7283f1f3320bf2ee7085ee252d4e7e_1+3ddb22772862a8223640fa97580569924f51bddc-r21:
> task do_configure: Succeeded
> NOTE: Tasks Summary: Attempted 299 tasks of which 298 didn't need to be
> rerun and 0 failed.
> Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake
> --help' for usage information.
> Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake
> --help' for usage information.
> rber@yocto-1:~/projects/yocto/yocto_for_trainer/sandbox_work$

That'll teach me to write off the top of my head when I'm not near my
primary development box :) I'm back in the office now and will send a follow
up to this shortly.

Bruce

>
>
> Regards,
>
> Robert..."The wonderful thing about standards is that there are so many
> of them to choose from." - (Amazing) Grace Murray Hopper, as quoted in
> the Unix Haters Handbook, p.10
>
> My public pgp key is available at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
>
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: workflow - kernel config

[Richard Purdie]

On Fri, 2011-11-04 at 15:15 -0400, Bruce Ashfield wrote:
> On Fri, Nov 4, 2011 at 1:23 PM, Robert Berger
> <gmane@reliableembeddedsystems.com> wrote:
> > Hi,
> >
> > I'm playing with poky-edison-6.0 and the default 2.6.37.6 kernel on a
> > beagle board with core-image-sato-sdk.
> >
> > Interestingly enough there is user space support e.g. for oprofile, but
> > oprofile is not configured in the kernel.
> >
> > The same for lacencytop and powertop,...
> 
> We have feature descriptions for all of the above as components in the
> linux-yocto
> kernel repository, but they do need to be turned on and tested on a per board
> basis.
> 
> We can trigger kernel options based on userspace packages being enabled or
> disabled, but that still wouldn't be a guarantee that they'd work. The
> options that
> are within the tree are a documentation of what has actually been tested.
> 
> The 2.6.37 tree was a transition point,and we've continued standardizing the
> options and feature set in the later kernels. For yocto 1.2 we'll have a better
> defined and consistent set of feature blocks. It's a building process
> and we move
> forward.
> 
> As others will point out there are other/deeper beagle board BSPs and layers
> (i.e. meta-texasinstruments) that likely already have support for these options\
> (but I haven't checked recently), so that's an avenue to explore as well.
> 
> >
> > So I was wondering what's the preferred workflow to start with the
> > "yocto-default" kernel config and add kernel configuration options
> > afterwards.
> >
> > What's I've tried so far is:
> >
> > bitbake virtual/kernel -c clean
> > bitbake virtual/kernel -c configure
> > bitbake virtual/kernel -c menuconfig
> > bitbake virtual/kernel -c compile
> > bitbake virtual/kernel -c deploy
> 
> This is one flow that will work to make changes to the default kernel, and
> test them on a board. I use something like:
> 
>  bitbake -f -c configure linux-yocto
>  bitbake -f -c menuconfig
>  bitbake -c linux-yocto

I suspect you mean:

bitbake -f -c configure linux-yocto
bitbake -f -c menuconfig
bitbake linux-yocto

:)

Cheers,

Richard
 

Re: workflow - kernel config

[Bruce Ashfield]

On Mon, Nov 7, 2011 at 11:39 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2011-11-04 at 15:15 -0400, Bruce Ashfield wrote:
>> On Fri, Nov 4, 2011 at 1:23 PM, Robert Berger
>> <gmane@reliableembeddedsystems.com> wrote:
>> > Hi,
>> >
>> > I'm playing with poky-edison-6.0 and the default 2.6.37.6 kernel on a
>> > beagle board with core-image-sato-sdk.
>> >
>> > Interestingly enough there is user space support e.g. for oprofile, but
>> > oprofile is not configured in the kernel.
>> >
>> > The same for lacencytop and powertop,...
>>
>> We have feature descriptions for all of the above as components in the
>> linux-yocto
>> kernel repository, but they do need to be turned on and tested on a per board
>> basis.
>>
>> We can trigger kernel options based on userspace packages being enabled or
>> disabled, but that still wouldn't be a guarantee that they'd work. The
>> options that
>> are within the tree are a documentation of what has actually been tested.
>>
>> The 2.6.37 tree was a transition point,and we've continued standardizing the
>> options and feature set in the later kernels. For yocto 1.2 we'll have a better
>> defined and consistent set of feature blocks. It's a building process
>> and we move
>> forward.
>>
>> As others will point out there are other/deeper beagle board BSPs and layers
>> (i.e. meta-texasinstruments) that likely already have support for these options\
>> (but I haven't checked recently), so that's an avenue to explore as well.
>>
>> >
>> > So I was wondering what's the preferred workflow to start with the
>> > "yocto-default" kernel config and add kernel configuration options
>> > afterwards.
>> >
>> > What's I've tried so far is:
>> >
>> > bitbake virtual/kernel -c clean
>> > bitbake virtual/kernel -c configure
>> > bitbake virtual/kernel -c menuconfig
>> > bitbake virtual/kernel -c compile
>> > bitbake virtual/kernel -c deploy
>>
>> This is one flow that will work to make changes to the default kernel, and
>> test them on a board. I use something like:
>>
>>  bitbake -f -c configure linux-yocto
>>  bitbake -f -c menuconfig
>>  bitbake -c linux-yocto
>
> I suspect you mean:
>
> bitbake -f -c configure linux-yocto
> bitbake -f -c menuconfig
> bitbake linux-yocto

Heh. Indeed. Random use of -c does not produce the results that
one is looking for.

Bruce

>
> :)
>
> Cheers,
>
> Richard
>
>
>
>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: workflow - kernel config

[Darren Hart]

On 11/07/2011 09:58 AM, Bruce Ashfield wrote:
> On Mon, Nov 7, 2011 at 11:39 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Fri, 2011-11-04 at 15:15 -0400, Bruce Ashfield wrote:
>>> On Fri, Nov 4, 2011 at 1:23 PM, Robert Berger
>>> <gmane@reliableembeddedsystems.com> wrote:
>>>> Hi,
>>>>
>>>> I'm playing with poky-edison-6.0 and the default 2.6.37.6 kernel on a
>>>> beagle board with core-image-sato-sdk.
>>>>
>>>> Interestingly enough there is user space support e.g. for oprofile, but
>>>> oprofile is not configured in the kernel.
>>>>
>>>> The same for lacencytop and powertop,...
>>>
>>> We have feature descriptions for all of the above as components in the
>>> linux-yocto
>>> kernel repository, but they do need to be turned on and tested on a per board
>>> basis.
>>>
>>> We can trigger kernel options based on userspace packages being enabled or
>>> disabled, but that still wouldn't be a guarantee that they'd work. The
>>> options that
>>> are within the tree are a documentation of what has actually been tested.
>>>
>>> The 2.6.37 tree was a transition point,and we've continued standardizing the
>>> options and feature set in the later kernels. For yocto 1.2 we'll have a better
>>> defined and consistent set of feature blocks. It's a building process
>>> and we move
>>> forward.
>>>
>>> As others will point out there are other/deeper beagle board BSPs and layers
>>> (i.e. meta-texasinstruments) that likely already have support for these options\
>>> (but I haven't checked recently), so that's an avenue to explore as well.
>>>
>>>>
>>>> So I was wondering what's the preferred workflow to start with the
>>>> "yocto-default" kernel config and add kernel configuration options
>>>> afterwards.
>>>>
>>>> What's I've tried so far is:
>>>>
>>>> bitbake virtual/kernel -c clean
>>>> bitbake virtual/kernel -c configure
>>>> bitbake virtual/kernel -c menuconfig
>>>> bitbake virtual/kernel -c compile
>>>> bitbake virtual/kernel -c deploy
>>>
>>> This is one flow that will work to make changes to the default kernel, and
>>> test them on a board. I use something like:
>>>
>>>  bitbake -f -c configure linux-yocto
>>>  bitbake -f -c menuconfig
>>>  bitbake -c linux-yocto
>>
>> I suspect you mean:
>>
>> bitbake -f -c configure linux-yocto
>> bitbake -f -c menuconfig
>> bitbake linux-yocto
> 
> Heh. Indeed. Random use of -c does not produce the results that
> one is looking for.

Close. Still need the target for menuconfig as well. Details ;-)

$ bitbake linux-yocto -c configure -f
$ bitbake linux-yocto -c menuconfig -f
$ bitbake linux-yocto


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

Re: workflow - kernel config

[Robert Berger]

What seems to work is this:

bitbake virtual/kernel -c configure -f
bitbake virtual/kernel -c menuconfig -f
bitbake virtual/kernel -c deploy -f
bitbake virtual/kernel

As long as the new kernel configurations are statically linked into the
kernel there is no need to generate modules and install them on the
rootfs. It's sufficient to update the uImage.

Regards,

Robert
...To the optimist, the glass is half full. To the pessimist, the glass
is half empty. To the engineer, the glass is twice as big as it needs to
be.So, if you let the engineer at it (fix the glass), the optimist,
while pretty happy, becomes happier and the pessimist becomes ecstatic.

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1