On Thu, Jul 21, 2011 at 1:36 PM, Bruce Ashfield <bruce.ashfi...@gmail.com> wrote: > 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.
bumping this old thread (by replying to myself), this hasn't been forgotten, and I spent considerable time on some docs last week. I've got a few small sections remaining to complete (but important sections), and I'll have some reasonable docs that I can send out in the next day or so. Cheers, Bruce > >> >> 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" > -- "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