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

[Bruce Ashfield]

On 12-10-16 6:49 PM, Darren Hart wrote:
>
>
> On 10/16/2012 09:42 AM, Bruce Ashfield wrote:
>> 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.
>
>
> OK, I'm seeing the following in my meta-in-master testing:
>
> | DEBUG: Executing shell function do_compile
> | NOTE: make -j 12 include/linux/version.h CC=i586-poky-linux-gcc
> --sysroot=/build/poky/master/qemux86_SZ60LW/tmp/sysroots/qemux86
> LD=i586-poky-linux-ld
> --sysroot=/build/poky/master/qemux86_SZ60LW/tmp/sysroots/qemux86
> |   GEN
> /build/poky/master/qemux86_SZ60LW/tmp/work/qemux86-poky-linux/linux-yocto-custom-3.4+git3+505590204542709b58d454f8ad20013f5cdcfede-r1/linux-qemux86-standard-build/Makefile
> | scripts/kconfig/conf --silentoldconfig Kconfig
> | make[2]: *** No rule to make target `include/linux/version.h'.  Stop.
>
>
> include/linux/version.h is a generated file, I'm not sure what would
> cause this to fail...
> running "ARCH=i386 make -j 12" in the source directory manually succeeds.
>
> Update: This appears to be a change in the upstream Makefile, we have an
> update to kernel.bbclass to make. I'm still interested in your thoughts

This is odd .. since I've built all the way up through 3.6+ in
my testing and haven't seen it. So it definitely is new, is it the
uapi changes causing problems ?

> on the following:
>
> This is building linux from current linus master with the following in meta:
>
> meta
> └── cfg
>      └── kernel-cache
>          ├── bsp
>          │   └── testbsp
>          │       ├── testbsp-standard.scc
>          │       └── testbsp.cfg
>          └── ktypes
>              └── standard
>                  └── standard.scc
>
> $ find meta -name "*.scc" | xargs cat
> standard.scc:
> define KERNEL_VERSION 3.5
>
> I wasn't sure what I needed to include here, so I just tossed this in
> following base.scc as a guide.
>
> testbsp-standard.scc:
> define KMACHINE testbsp
> define KTYPE standard
> define KARCH i386
> include ktypes/standard
> kconf hardware testbsp.cfg

This works, if you don't want the ktypes/standard in your meta
tree, you don't need it. I tested without one in mine, just the
bsp/ subdir. Pulling in the yocto-kernel-cache 'cfg' subdir for
reuse is also something to consider (sneak a little reuse in ;)

>
> Finally, the linux-yocto-custom.bbappend contains:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> COMPATIBLE_MACHINE_qemux86 = "qemux86"
> KMACHINE_qemux86 = "testbsp"
> KTYPE="standard"
> KBRANCH="master"
> KMETA=""

This should be the default, so you don't need it in your file, I didn't
have it in mine.

> SRC_URI="git:///home/dvhart/source/linux/linux;protocol=file"
> SRCREV="505590204542709b58d454f8ad20013f5cdcfede"
>
>
> Anything look out of place here? How does this compare with what you tested?

Very close, and it should work fine.

Bruce

>
>