[linux-yocto] Linux-yocto-custom and meta-data

Bruce Ashfield bruce.ashfield at windriver.com
Tue Oct 16 09:24:01 PDT 2012

On 12-10-16 12:17 PM, Darren Hart wrote:
> On 10/16/2012 09:03 AM, Bruce Ashfield wrote:
>> On 12-10-15 8:00 PM, Darren Hart wrote:
>>> On 10/15/2012 04:56 PM, Bruce Ashfield wrote:
>>>> On 12-10-15 7:47 PM, Darren Hart wrote:
>>>>> On 10/15/2012 04:42 PM, Bruce Ashfield wrote:
>>>>>> On 12-10-15 7:26 PM, Darren Hart wrote:
>>>>>>> I've got a customer that insists on using their own kernel version, but
>>>>>>> doesn't want to keep their config in recipe-space. I already have them
>>>>>>> using linux-yocto-custom with a linux 3.5 based git repository. Seems to
>>>>>>> me the best way to address this would be for them to create a meta
>>>>>>> directory in their master branch which contains their BSP definition. Is
>>>>>>> it as simple as the following?
>>>>>>>       $ tree meta
>>>>>>>       meta/cfg/kernel-cache/bsp/common-pc
>>>>>>>       └── cfg
>>>>>>>           └── kernel-cache
>>>>>>>               └── bsp
>>>>>>>                   └── mybsp
>>>>>>>                       ├── mybsp.cfg
>>>>>>>                       └── mybsp.scc
>>>>>>> Where mybsp.scc is:
>>>>>>>       define KMACHINE mybsp
>>>>>>>       define KARCH i386
>>>>>>>       kconf hardware mybsp.cfg
>>>>>>> This doesn't define any kernel types, would we need to do that, or can
>>>>>>> the tools deal with that?
>>>>>> The tools want to search by kmachine + ktype. In theory they can just
>>>>>> search on one and get the best match, so taking the default ktype of
>>>>>> standard *should* work (and not specifying it in the .scc, but it
>>>>>> should still be passed to the tools).
>>>>> So if I specify KTYPE=standard and MACHINE=mybsp, then I should be able
>>>>> to get away with:
>>>>>       meta
>>>>>       └── cfg
>>>>>           └── kernel-cache
>>>>>               └── bsp
>>>>>                   └── mybsp
>>>>>                       ├── mybsp.cfg
>>>>>                       └── mybsp-standard.scc
>>>>> Note the mybsp-standard.scc name, and the lack of a
>>>>> ktype/standard/standard.scc.
>>>> Yep. Both are ok, and you don't even need to call it -standard.scc,
>>>> since the file name isn't searched, only the contents for the right
>>>> ktype/kmachine that best matches the machine+ktype passed down from
>>>> the build system.
>>> Ah, so mybsp.scc should contain:
>>>     define KMACHINE mybsp
>>>     define KARCH i386
>>>     define KTYPE standard
>>>     kconf hardware mybsp.cfg
>> I tested this, and as we thought, it does want the KTYPE to be defined.
>> I already have a patch to remove that requirement, and I'll queue it for
>> 1.4.
>> One word of warning though. Due to the way that the branches are reset
>> and the way that git handles the base/origin commit, make sure you
>> have one commit BEFORE you add your BSP content onto the meta branch.
>> You'll also need to set KMETA=meta in your linux-yocto-custom to trigger
>> the checkout of the meta data.
>> If you have any trouble with the meta branch creation, shout, since it
>> definitely shouldn't contain the content from the master branch, or it'll
>> be reset just like any BSP branch!
> Awesome, I was just about to sit down to start - thanks a lot!
> I don't think the separate meta branch is going to fly. The goal here is
> to make it trivial to use a traditional kernel development cycle with the
> Linux kernel sources, and have their .config checked in to revision control.
> If they have to checkout a meta branch in order to find the .cfg, they won't
> do it. They just want a way to build their kernel with Yocto using a config
> that is in the sources.
> Can we do this with meta just being included in the master branch?

Not with the current scripts. That's the 'merged meta' approach that I 
tried and we decided was to noisy. Or at least nothing that has been
tested in over a year now.

If you put meta dir right in the branch .. it should be found, but I'd
have to try it to see what blows up.




More information about the linux-yocto mailing list