On Thu, Jul 21, 2011 at 1:23 PM, Anders Darander <and...@chargestorm.se> wrote: > > On 20 jul 2011, at 22:18, "Bruce Ashfield" <bruce.ashfi...@gmail.com> wrote: > >> On Wed, Jul 20, 2011 at 11:45 AM, Koen Kooi <k...@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.ashfi...@gmail.com> wrote: >>>>> On Fri, Jul 15, 2011 at 11:02 AM, Phil Blundell <ph...@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 <p...@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@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" _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
