diff --git a/documentation/kernel-manual/kernel-how-to.xml b/documentation/kernel-manual/kernel-how-to.xml
index abb19f285c..3ca17465c4 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.