[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.
Cheers,
Bruce
>
>
More information about the linux-yocto
mailing list