>From: Bruce Ashfield >Sent: Tuesday, November 23, 2010 1:09 AM > >On 10-11-18 05:36 AM, Chris Tapp wrote: >> Hi, >> >> I've been evaluating OpenEmbedded and saw the announcement of 'Yocto' >> on the mailing list. Yocto looks like it may be better for my needs as >> it is more refined. >> >> As there isn't currently support for the ALIX 3D3 (a Geode LX based >> system), I am interested in creating and maintaining a BSP for it. >> This should also work with other LX systems (e.g. SUMO ST166, other >> ALIX variants), some with no changes, some with minor ones. >> >> Could you give me an idea how much work would be involved in doing >> this and what it involve?
Kernel is the biggest part you'd work out which thanks to Bruce you should have rich information below. Besides, you may also have some board specific firmware, 3rd party components, xserver, etc. Generally speaking, you need create a new layer which bundles all board specific bits together which are then added on top of poky core layer. You can read http://www.yoctoproject.org/sites/default/files/bsp-guide_4.pdf which has a detail description how a new BSP is created. You can also refer to existing layers such as meta-emenlow for reference. On the other hand, if all the variances you care about is just in kernel side, basically what Bruce describes is enough to create a new MACHINE. For example, you may refer to routerstationpro: commit 149f2262135ca87608783a8801c9c2d978d8c8ef Author: Bruce Ashfield <bruce.ashfi...@windriver.com> Date: Sun Oct 10 14:11:07 2010 -0400 routerstationpro: create machine conf and compatibility BUGID: 422 Add the machine configuration and kernel infrastructure for building the routerstation pro BSP. Signed-off-by: Bruce Ashfield <bruce.ashfi...@windriver.com> Hope above helps. Thanks, Kevin > >I can answer from the kernel point of view. > >The supported yocto kernel(s) (currently 2.6.34 and >shortly 2.6.37-rcX) are the place where I can assist >in getting you up and running with a new board/platform >fairly easily. > >The kernel documentation is being updated (since I've >made changes recently to streamline just what you >are talking about here), but I can give some more >hands on help while those docs are still outstanding. > >For the kernel, you'd need to create a machine.conf >with your optimization, features, etc, and give the >machine a name. There are obviously plenty of examples >on how to do this in the tree. > >At that point, you can bootstrap the the BSP process >by doing a: bitbake -c configure linux-yocto. > >You then have the kernel git repository staged and >branch for kernel changes to be added. Working with >the kernel in git is key, since you can have a >common branch, and have board specific branches for >configuration or features that are not generally >applicable to all boards. > >You can iteratively configure and build the board >from this point. > >When you are happy with the changes you can export >the patches, or keep the branches in a local git >tree (better), and if there is assistance in maintaining >the BSP(s) we can contribute them to the maintained >kernel repository (best). This then enables collaboration >and best practices development. > >The amount of work depends on the type of kernel >patches you need to add for the board(s) and the >desired feature mix. Userspace difficulty should >be manageable if the known working ARM baseline >builds are used as starting point. > >I've gone light on the details here, but if there is >interest, I can provide more information. > >And again, this is speaking from the kernel point of >view only. > >Cheers, > >Bruce > >> >> Chris Tapp >> >> opensou...@keylevel.com >> www.keylevel.com >> >> >> >> _______________________________________________ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > >_______________________________________________ >yocto mailing list >yocto@yoctoproject.org >https://lists.yoctoproject.org/listinfo/yocto _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
