diff --git a/documentation/kernel-manual/yocto-project-kernel-manual.xml b/documentation/kernel-manual/yocto-project-kernel-manual.xml index 6d93975019..1c247bcd74 100644 --- a/documentation/kernel-manual/yocto-project-kernel-manual.xml +++ b/documentation/kernel-manual/yocto-project-kernel-manual.xml @@ -360,7 +360,7 @@ kernel toolkit: -->
- How to get things accomplished with the kernel + How to Get Things Accomplished with the Kernel This section describes how to accomplish tasks involving the kernel's tree structure. The information covers the following: @@ -1163,7 +1163,7 @@ The following example illustrates one variant of this workflow: -->
- + -
+ + +
+ BSP: Creating + + This section provides an example for creating a BSP based on an existing, and hopefully, + similar one. + Follow these steps and keep in mind your particular situation and differences: + + Get a machine configuration file that matches your machine. + You can start with something in meta/conf/machine. + Or, meta-emenlow/conf/machine has an example in its own layer. + The most up-to-date machines that are probably most 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 Project kernel + at . + The main difference between them is that "emenlow" is in its own layer. + It is in its own layer because it needs extra machine-specific packages such as its + own video driver and other supporting packages. + The "atom-pc" is simpler and does not need any special packages - everything it needs can + be specified in the configuration file. + The "atom-pc" machine also supports all of Asus eee901, Acer Aspire One, Toshiba NB305, + and the Intel® Embedded Development Board 1-N450 with no changes. + If you want to make minor changes to support a slightly different machine, you can + create a new configuration file for it and add it alongside the others. + You might consider keeping the common stuff separate and including it. + Similarly, you can also use multiple configuration files for different machines even + if you do it as a separate layer like meta-emenlow. + As an example consider this: + + Copy meta-emenlow + Fix or remove anything you do not need. + For this example the only thing left was the kernel directory with a linux-yocto_git.bbappend + file (linux-yocto is the kernel listed in + meta-crownbay/conf/machine/crownbay.conf. + Finally, a new entry to the build/donf/bblayers.conf was added so the + new layer could be found by Bitbake. + + + Get an image with a working kernel built. + For the kernel to compile successfully, you need to create a branch in the git repository + specifically named for your machine. + So first create a bare clone of the Yocto Project 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. + Point the build at the new kernel git tree. + You can do this by commenting out the SRC_URI variable 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 do this in 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, select the machine in build/conf/local.conf: + + # + MACHINE ?= "crownbay" + # + + + You should now be able to build and boot an image with the new kernel: + + $ 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. + For example inserting the following into some .cfg file: + + CONFIG_NETDEV_1000=y + CONFIG_E1000E=y + + + And, another .cfg file would contain: + + 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. + However, the former method is probably easier. + If you're also adding patches to the kernel, you can do the same thing. + 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: + + build/tmp/work/crownbay-poky-linux/linux-yocto-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+ +0431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux + + + Then, 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. + For example, in this case, commit the patch to the crownbay-standard branch, and during the + next build it will be applied from there. + + +
+ + + + + + + + + -
+ + -->