Date
1 - 4 of 4
New platforms
|
Chris Tapp
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? Chris Tapp opensource@... www.keylevel.com |
|
|
|
Bruce Ashfield <bruce.ashfield@...>
On 10-11-18 05:36 AM, Chris Tapp wrote:
Hi,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
|
|
|
|
Tian, Kevin <kevin.tian@...>
From: Bruce AshfieldKernel 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.ashfield@...> 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.ashfield@...> Hope above helps. Thanks, Kevin
|
|
|
|
Tom Zanussi <tom.zanussi@...>
On Thu, 2010-11-18 at 02:36 -0800, Chris Tapp wrote:
Hi,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 |
|
|