[yocto] Selecting different kernel inside an image recipe

Mike Looijmans mike.looijmans at topic.nl
Wed Aug 5 00:10:12 PDT 2015


There are several solutions:

- Pick one kernel as the "master" one. Create recipes for alternative kernels 
as required, but blank the (R)PROVIDES so that they do not "provide" a kernel 
and bitbake will treat them as yet another package to build. In the scripts 
that you use to deploy the images, pick the kernel that you want.

- Create a new MACHINE for each alternative.

- Set up multiple build environments, share the sstate-cache and similar 
directories. Each environment can then pick its own kernel etc.


On 04-08-15 06:15, Klaus Knopper wrote:
> Hello Bruce & list,
>
> I need to come back to the topic after quite some failed attempts to
> solve the problem of switching kernel configurations specific to an
> image recipe.
>
> On Wed, Jul 08, 2015 at 01:30:54PM -0400, Bruce Ashfield wrote:
>> On 2015-07-08 12:36 PM, Klaus Knopper wrote:
>>> Hello Leonardo,
>>>
>>> On Wed, Jul 08, 2015 at 10:40:10AM -0500, Leonardo Sandoval wrote:
>>>> On 07/08/2015 09:50 AM, Klaus Knopper wrote:
>>>>> Hello list,
>>>>>
>>>>> I'm trying to build variantions/brands of an image that only differ in
>>>>> kernel configuration and kernel modules included, but everything else stays
>>>>> the same, for the exact same board, as in the main image.
>>>>>
>>>>> Setting PREFERRED_PROVIDER_virtual/kernel = "different_kernel"
>>>>> right inside in the new image recipe does not have any effect, as that
>>>>> variable seems to be evaluated exclusively in the local.conf machine
>>>>> file, which is read by all recipes.
>>>>
>>>> This variable is commonly used inside configuration metadata (machine or
>>>> distro conf files). You may try it there.
>>>
>>> Please help me to understand your answer: You are saying that I do have
>>> to change the machine or distro config used for ALL recipes, to be able
>>> to use a different kernel configuration in ONE recipe, right?
>>>
>>> I was really trying to avoid that. :-(
>>>
>>> So it is really not possible to just select a different kernel config
>>> within a normal recipe without changing the global configuration?
>>
>> You really want a different kernel recipe to provide that different
>> kernel configuration.  Which looks to be what you are describing, and
>> you just want to switch the provider (again, what you are saying).
>
> Yes, and I had indeed already added a new kernel recipe, which builds
> the desired kernel as uImage when calling "bitbake kernel-recipename"
> directly, but it's ignored by the image recipes. All of them use only
> the kernel that's defined in build/conf/local.conf as
> PREFERRED_PROVIDER_virtual/kernel . Redefining the variable in the image
> recipes has no effect.
>
>> Changing the included kernel via that different kernel recipe/package
>> name, and setting it via the preferred provider is the same as any
>> bitbake variable.
>
> I thought so, but apparently I'mmissing something. It looks like
> PREFERRED_PROVIDER_virtual/kernel only works in local.conf, i.e. I need
> to fork the project or change the local.conf file each time I want to
> use a different kernel. Is this a known or desired behavior?
>
>> So you should be able to set it in any .conf file, and then have what
>> you want.
>
> So, can you confirm that it is not possible to set
> PREFERRED_PROVIDER_virtual/kernel inside an image recipe?
>
>> I've used layers with layer.conf files, and similar mechanisms
>> to do what you are trying in the past .. but the longer serving oe/bitbake
>> folks may have a better example to point at.
>
> If there are examples for a more convenient way to switch kernels in a
> recipe rather than inside a .conf file, please point me to the right
> direction.
>
> Regards
> -Klaus
>



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail








More information about the yocto mailing list