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

[Darren Hart]

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?


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