From c6f06f478ac229c4619f815b8b313711d47b1551 Mon Sep 17 00:00:00 2001 From: Tom Zanussi Date: Mon, 14 Mar 2011 00:36:28 -0500 Subject: documentation: Kernel Manual fixes Upgraded to reflect 1.0 usage rather than 0.90 usage, and some other clarifications and minor changes. [RP - added tweaks suggested by Darren Hart] Signed-off-by: Tom Zanussi Signed-off-by: Richard Purdie --- documentation/kernel-manual/kernel-how-to.xml | 124 ++++++++++++++------------ 1 file changed, 65 insertions(+), 59 deletions(-) diff --git a/documentation/kernel-manual/kernel-how-to.xml b/documentation/kernel-manual/kernel-how-to.xml index abb19f285..3ca17465c 100644 --- a/documentation/kernel-manual/kernel-how-to.xml +++ b/documentation/kernel-manual/kernel-how-to.xml @@ -425,18 +425,18 @@ repository. # full description of the changes - > git whatchanged <kernel type>..<bsp>-<kernel type> - > eg: git whatchanged standard..common_pc-standard + > git whatchanged <kernel type>..<kernel type>/<bsp> + > eg: git whatchanged yocto/standard/base..yocto/standard/common-pc/base # summary of the changes - > git log --pretty=oneline --abbrev-commit <kernel type>..<bsp>-<kernel type> + > git log --pretty=oneline --abbrev-commit <kernel type>..<kernel type>/<bsp> # source code changes (one combined diff) - > git diff <kernel type>..<bsp>-<kernel type> - > git show <kernel type>..<bsp>-<kernel type> + > git diff <kernel type>..<kernel type>/<bsp> + > git show <kernel type>..<kernel type>/<bsp> # dump individual patches per commit - > git format-patch -o <dir> <kernel type>..<bsp>-<kernel type> + > git format-patch -o <dir> <kernel type>..<kernel type>/<bsp> # determine the change history of a particular file > git whatchanged <path to file> @@ -467,9 +467,9 @@ repository. # determine which branches contain a feature > git branch --contains <tag> - # show the changes in a kernel type - (0.9 examples) - > git whatchanged wrs_base..<kernel type> - > eg: git whatchanged wrs_base..standard + # show the changes in a kernel type + > git whatchanged yocto/base..<kernel type> + > eg: git whatchanged yocto/base..yocto/standard/base @@ -733,10 +733,10 @@ repository. For example, the following command pushes the changes from your local branch - common_pc-standard to the remote branch with the same name - in the master repository //git.mycompany.com/pub/git/kernel-2.6.27. + yocto/standard/common-pc/base to the remote branch with the same name + in the master repository //git.mycompany.com/pub/git/kernel-2.6.37. - > push ssh://git.mycompany.com/pub/git/kernel-2.6.27 common_pc-standard:common_pc-standard + > push ssh://git.mycompany.com/pub/git/kernel-2.6.37 yocto/standard/common-pc/base:yocto/standard/common-pc/base @@ -866,9 +866,9 @@ repository. The following commands illustrate some of the steps you could use to - import the common_pc-standard kernel into a secondary SCM: + import the yocto/standard/common-pc/base kernel into a secondary SCM: - > git checkout common_pc-standard + > git checkout yocto/standard/common-pc/base > cd .. ; echo linux/.git > .cvsignore > cvs import -m "initial import" linux MY_COMPANY start @@ -881,8 +881,8 @@ repository. The following commands illustrate how you can condense and merge two BSPs into a second SCM: - > git checkout common_pc-standard - > git merge common_pc_64-standard + > git checkout yocto/standard/common-pc/base + > git merge yocto/standard/common-pc-64/base # resolve any conflicts and commit them > cd .. ; echo linux/.git > .cvsignore > cvs import -m "initial import" linux MY_COMPANY start @@ -1006,9 +1006,12 @@ That's it. Configure and build. Creating a BSP Based on an Existing Similar BSP - This section provides an example for creating a BSP that is based on an existing, and hopefully, - similar one. - Follow these steps and keep in mind your particular situation and differences: + This section provides an example for creating a BSP + that is based on an existing, and hopefully, similar + one. It assumes you will be using a local kernel + repository and will be pointing the kernel recipe at + that. Follow these steps and keep in mind your + particular situation and differences: @@ -1016,16 +1019,14 @@ That's it. Configure and build. - You can start with something in meta/conf/machine. - Or, meta-emenlow/conf/machine has an example in its own layer. + You can start with something in meta/conf/machine - + meta/conf/machine/atom-pc.conf for example. Or, you can start with a machine + configuration from any of the BSP layers in the meta-intel repository at + , such as + meta-intel/meta-emenlow/conf/machine/emenlow.conf. - 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 files were either just added or upgraded to use the Yocto Project kernel - at . The main difference between the two 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. @@ -1049,19 +1050,21 @@ That's it. Configure and build. As an example consider this: - Copy meta-emenlow + Copy meta-emenlow to meta-mymachine Fix or remove anything you do not need. For this example the only thing left was the kernel directory with a - linux-yocto-stable_git.bbappend file - (linux-yocto-stable is the kernel listed in - meta-crownbay/conf/machine/crownbay.conf. + linux-yocto_git.bbappend + file + and meta-mymachine/conf/machine/mymachine.conf + (linux-yocto is the kernel listed in + meta-emenlow/conf/machine/emenlow.conf). Add a new entry in the build/conf/bblayers.conf so the new layer can be found by Bitbake. - Get an image with a working kernel built. + Create a machine branch for your machine. @@ -1070,58 +1073,52 @@ That's it. Configure and build. To create this branch first create a bare clone of the Yocto Project git repository. Next, 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 + $ git clone --bare git://git.pokylinux.org/linux-yocto-2.6.37.git + linux-yocto-2.6.37.git + $ git clone linux-yocto-2.6.37.git linux-yocto-2.6.37 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 + $ git checkout -b yocto/standard/mymachine origin/yocto/standard/base + $ git push origin yocto/standard/mymachine:yocto/standard/mymachine - - - - At this point, your git tree should compile. - + - In a layer, create a linux-yocto-stable_git.bbappend + In a layer, create a linux-yocto_git.bbappend file with the following: - COMPATIBLE_MACHINE = ${MACHINE} + FILESEXTRAPATHS := "${THISDIR}/${PN}" + COMPATIBLE_MACHINE_mymachine = "mymachine" # It is often nice to have a local clone of the kernel repository, to # allow patches to be staged, branches created, and so forth. Modify # KSRC to point to your local clone as appropriate. - # KSRC ?= /path/to/your/bare/clone/yocto-kernel + KSRC ?= /path/to/your/bare/clone/for/example/linux-yocto-2.6.37.git - # KMACHINE is the branch to be built, or alternateively + # KMACHINE is the branch to be built, or alternatively # KBRANCH can be directly set. + # KBRANCH is set to KMACHINE in the main linux-yocto_git.bb + # KBRANCH ?= "${LINUX_KERNEL_TYPE}/${KMACHINE}" - # KBRANCH ?= "${KMACHINE}-${LINUX_KERNEL_TYPE}" + KMACHINE_mymachine = "yocto/standard/mymachine" - # SRC_URI = "git://${KSRC};nocheckout=1;branch=${KBRANCH},meta;name=machine,meta" + SRC_URI = "git://${KSRC};nocheckout=1;branch=${KBRANCH},meta;name=machine,meta" - - In the previous sample file you need to update and remove the comment from - the KSRC assignment and also remove the comment from the SRC_URI line. - - After doing that, select the machine in build/conf/local.conf: # - MACHINE ?= "crownbay" + MACHINE ?= "mymachine" # @@ -1131,6 +1128,10 @@ That's it. Configure and build. $ bitbake poky-image-sato-live + + + + Modify the kernel configuration for your machine. @@ -1149,17 +1150,22 @@ That's it. Configure and build. And, another .cfg file would contain: CONFIG_LOG_BUF_SHIFT=18 + - http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/ + + These config fragments could then be picked up and + applied to the kernel .config by appending them to the kernel SRC_URI: + - SRC_URI_append_crownbay = " file://some.cfg \ + + SRC_URI_append_mymachine = " file://some.cfg \ file://other.cfg \ " - You could also add these directly to the git repository wrs_meta + You could also add these directly to the git repository meta branch as well. However, the former method is a simple starting point. @@ -1173,7 +1179,7 @@ That's it. Configure and build. 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+ + build/tmp/work/mymachine-poky-linux/linux-yocto-2.6.37+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+ 0431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux @@ -1182,7 +1188,7 @@ That's it. Configure and build. Then, modify the code there, using quilt to save the changes, and recompile until it works: - $ bitbake -c compile -f linux-yocto-stable + $ bitbake -c compile -f linux-yocto @@ -1191,7 +1197,7 @@ That's it. Configure and build. SRC_URI location. The patch is 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 + For example, in this case, commit the patch to the "yocto/standard/mymachine" branch, and during the next build it is applied from there. -- cgit v1.2.3