On Thu, 2010-11-18 at 02:36 -0800, 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? >
I can give you a bit of an idea from a practical standpoint, since I've also started working on a BSP for a new board just recently (i.e. I'm actually still on the learning curve myself, hopefully anyone who knows better will correct any of errors or misconceptions...) As mentioned by Bruce, things have changed lately as far as bootstrapping a board - it should be easier now, but something like the below should work to get you started. As also mentioned by Bruce, you need a machine.conf that describes your machine - there are a bunch of examples to start from, in a couple of places, a bunch in in meta/conf/machine and another example that's part of its own layer, in meta-emenlow/conf/machine. The most recently up-to-date machines that are probably more similar to yours and that you might want to look at are meta/conf/machine/atom-pc.conf and meta-emenlow/conf/machine/emenlow.conf. Both of these were either just added or upgraded to use the yocto kernel (http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/). The main difference between them is that the emenlow is in its own layer, because it needs some extra machine-specific packages such as its own video driver and supporting packages, etc. The atom-pc is simpler and doesn't need any special packages - everything it needs can be specified in the .conf file. Note also that this one machine (atom-pc) supports all of Asus eee901, Acer Aspire One, Toshiba NB305, and Intel BlackSand with no changes. If you wanted to make minor changes to support a slightly different machine, you could create a new .conf for it and add it alongside the others (maybe keeping the common stuff separate and including it). Similarly, you can also use multiple .confs for different machines even if you do it as a separate layer like meta-emenlow. So anyway, for my new layer, meta-crownbay, I basically made a copy of meta-emenlow and fixed it up/removed anything I didn't need - in meta-crownbay/recipes, the only thing left was the kernel dir with a linux-yocto_git.bbappend file in it (linux-yocto is the kernel listed in meta-crownbay/conf/machine/crownbay.conf). I added a new entry to build/conf/bblayers.conf so the new layer can be found by bitbake. So to get things working, the main thing to start out with is to get an image with a working kernel built. For the kernel to compile successfully, you need to create a branch in the git repo specifically named for your machine. So first create a bare clone of the windriver git repository, and then create a local clone of that: $ git clone --bare git://git.pokylinux.org/linux-2.6-windriver.git linux-2.6-windriver.git $ git clone linux-2.6-windriver.git linux-2.6-windriver Now create a branch in the local clone and push it to the bare clone: $ git checkout -b crownbay-standard origin/standard $ git push origin crownbay-standard:crownbay-standard At this point, your git tree should be set up well enough to compile, now you just need to point the build at the new kernel git tree, by commenting out the SRC_URI in meta/recipes-kernel/linux/linux-yocto_git.bb and using a SRC_URI that points to your new bare git tree (you should also be able to add this in the do this in the linux-yocto_git.bbappend in the layer): # To use a staged, on-disk bare clone of a Wind River Kernel, use a # variant of the below # SRC_URI = "git://///path/to/kernel/default_kernel.git;fullclone=1" SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \ git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta" After doing that, and selecting the machine in build/conf/local.conf e.g. MACHINE ?= "crownbay" you should be able to build and boot an image with the new kernel (e.g. bitbake poky-image-sato-live). Of course, that will give you a kernel with the default config, which is probably not what you want. If you just want to set some kernel config options, you can do that by putting them in a files, say some.cfg containing: CONFIG_NETDEV_1000=y CONFIG_E1000E=y and some other.cfg containing CONFIG_LOG_BUF_SHIFT=18 http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/ SRC_URI_append_crownbay = " file://some.cfg \ file://other.cfg \ " You could also add these directly to the git repo's wrs_meta branch as well, but this is probably easier. If you're also adding patches to the kernel, you can do the same thing, and put your patches in the SRC_URI as well (plus .cfg for their kernel config options if needed). Practically speaking, to generate the patches, you'd go to the source in the build tree, for example, build/tmp/work/crownbay-poky-linux/linux-yocto-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+ 0431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux and modify the code there, using quilt to save the changes, and recompile (bitbake -c compile -f) until it works. Once you have the final patch from quilt, copy it to the SRC_URI location, and it should be applied the next time you do a clean build. Of course, since you have a branch for the BSP in git, it would be better to put it there instead e.g. in my case, commit the patch to the crownbay-standard branch, and next build it will be applied from there. I know some of the above is the old way of doing things, and I'm sure other could offer a more efficient development cycle, but that's what I'm currently using and it works for me for now. This is only some basic practical stuff to help get started - you really want to look at the Poky Reference Manual for much more useful info on actually what things in the recipes actually mean, etc.: http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html One section of that is a 'BSP guide' which is available separately here: http://www.yoctoproject.org/sites/default/files/bsp-guide_2.pdf We'd really like to expand that with whatever additional info might be useful to BSP developers, so please let us know if you have suggestions. Thanks, Tom > 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
