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

[Bruce Ashfield]

On 12-10-16 12:24 PM, Bruce Ashfield wrote:
> 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.

Imagine that .. the old code held up. So with the ktype and meta
committed right to the master branch, KMETA left unset, it should pick
it up and build it fine.

Bruce

>
> Cheers,
>
> Bruce
>
>>
>>
>
> _______________________________________________
> linux-yocto mailing list
> linux-yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto