[OE-core] kernels

[Anders Darander]

On 21 jul 2011, at 19:36, "Bruce Ashfield" <bruce.ashfield at gmail.com> wrote:

> On Thu, Jul 21, 2011 at 1:23 PM, Anders Darander <anders at chargestorm.se> wrote:
>> 
>> On 20 jul 2011, at 22:18, "Bruce Ashfield" <bruce.ashfield at gmail.com> wrote:
>> 
>>> On Wed, Jul 20, 2011 at 11:45 AM, Koen Kooi <koen at dominion.thruhere.net> wrote:
>>>> 
>>>> Op 20 jul 2011, om 17:42 heeft Bruce Ashfield het volgende geschreven:
>>>> 
>>>>> On Fri, Jul 15, 2011 at 11:36 AM, Bruce Ashfield
>>>>> <bruce.ashfield at gmail.com> wrote:
>>>>>> On Fri, Jul 15, 2011 at 11:02 AM, Phil Blundell <philb at gnu.org> wrote:
>>>>>>> On Fri, 2011-07-15 at 09:51 -0400, Bruce Ashfield wrote:
>>>>>>>> On Fri, Jul 15, 2011 at 9:21 AM, Phil Blundell <pb at pbcl.net> wrote:
>>>>>>>>> The other day I was working on a BSP layer for a fairly generic i586
>>>>>>>>> system and I was struck by the fact that we don't appear to have any
>>>>>>>>> vanilla kernel recipes in oe-core.  I had sort of expected that, to get
>>>>>>>>> a standard bzImage out, I would just need to ship an appropriate
>>>>>>>>> defconfig in my layer and everything else would "just work".
>>>>>>>> 
>>>>>>>> Hmm. Perhaps it isn't documented clearly enough as such, but the linux-yocto
>>>>>>>> kernel base can work in this mode, since that was a design goal of
>>>>>>>> 1.0.
>>>>>>>> 
>>>>>>>> You pick a branch, throw in a config fragment (or defconfig if you really
>>>>>>>> want)  and build. The base branches in the tree are generic enough to
>>>>>>>> sort a range of boards out of the box, and should form a base.
>>>>>>> 
>>>>>>> Okay, cool.  I'll give it a go and see how I get on.
>>>>>>> 
>>>>>>> Is there a description anywhere of what the functional differences are
>>>>>>> between the code in linux-yocto git and the upstream kernel.org tree?
>>>>>> 
>>>>>> It varies, and the variables are many, so I can answer this in several ways.
>>>>> 
>>>>> Following up on my own email. I'm just about to push out the 3.0
>>>>> kernel support / changes, so I'm seeing the light at the end of the tunnel
>>>>> and recalled that this is still hanging a bit.
>>>>> 
>>>>> Is there anything tangible you wanted me to do here ?  Create an example ?
>>>>> Write a short howto  .. or something else ?
>>>> 
>>>> A guide to make your own setup that isn't based on linux-yocto but which does work with the linux-yocto bbclass?
>>> 
>>> That's reasonable. Once I get the imminent kernel uprev out the door, I'll
>>> focus on something along these lines.
>> 
>> That sounds good. Upon re-reading the email, I wasn't really sure if the intent was a guide on how to supply your own configuration, or whether it was intended to be about how to integrate a custom BSP-kernel (preferably both tarball and directly from a local git repo). If it was the first, then I hope that later on we'll be able to derive a guide for developing a custom BSP-layer (it's the kernel part I'm interested in).
> 
> It was more the first in this case, but it can actually encompass the
> second. What would be covered here would be a special case of developing
> a custom layer. Taking some arbitrary source, configuration, patches, git trees
> and creating a kernel repo that would work with the linux-yocto tools and
> recipes.
> 
> The second topic of creating a custom BSP layer, doesn't (and shouldn't
> normally) have to go so far. A simple branch reference, or reference to
> a tree based on a known linux-yocto is all you need to build with linux-yocto
> for most custom BSPs. As for the source of that custom BSP (tarball or
> git) that would be covered in how to create that custom branch reference.
> 
>> 
>> Preferably first a guide on how to get a custom BSP kernel built from git, and later on, when there both are time available as well as some more stabilization, how to base my own BSP kernel on linux-yocto (eg. using linux-yocto as the upstream repo). It's unfortunately not always that likely that the BSP for some products will be mainlined...
> 
> I experience this every day as well .. bsp patches that will largely
> live forever, so
> I completely understand. The structure of the repos is created to manage just
> this sort of nagging patch and any crimes they may have committed. So this
> topic can be explicitly called out and worked on.
> 
> The basics are covered in the existing guides, but it sounds like some end
> to end use cases might be in order.

Sounds good.

I'll try to have a new look at the existing guides in a few weeks, but I guess that some end-to-end use cases would be helpful. Not least when it comes to try to combine a custom git repo based both on a custom BSP and linux-yocto (at least trying to sync it up to linux-yocto). 

I guess that I'm not alone in that I've not yet converted our old Linux recipes from oe-dev to be based on Linux-yocto (otoh, our developers are still working on our oe-dev based tree), so I'm not in a real hurry.

Cheers,
Anders