[OE-core] kernels

[Bruce Ashfield]

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.

Bruce

>
> Cheers,
> Anders
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"