[linux-yocto] Linux-yocto-custom and meta-data
Darren Hart
dvhart at linux.intel.com
Tue Oct 16 15:49:55 PDT 2012
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
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
Finally, the linux-yocto-custom.bbappend contains:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
COMPATIBLE_MACHINE_qemux86 = "qemux86"
KMACHINE_qemux86 = "testbsp"
KTYPE="standard"
KBRANCH="master"
KMETA=""
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?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
More information about the linux-yocto
mailing list