<literallayout class='monospaced'>
# 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>
# 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
</literallayout>
<para>
<para>
For example, the following command pushes the changes from your local branch
- <filename>common_pc-standard</filename> to the remote branch with the same name
- in the master repository <filename>//git.mycompany.com/pub/git/kernel-2.6.27</filename>.
+ <filename>yocto/standard/common-pc/base</filename> to the remote branch with the same name
+ in the master repository <filename>//git.mycompany.com/pub/git/kernel-2.6.37</filename>.
<literallayout class='monospaced'>
- > 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
</literallayout>
</para>
<para>
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:
<literallayout class='monospaced'>
- > 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
</literallayout>
<para>
The following commands illustrate how you can condense and merge two BSPs into a second SCM:
<literallayout class='monospaced'>
- > 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
<title>Creating a BSP Based on an Existing Similar BSP</title>
<para>
- 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:
<orderedlist>
<listitem><para>
</para>
<para>
- You can start with something in <filename>meta/conf/machine</filename>.
- Or, <filename>meta-emenlow/conf/machine</filename> has an example in its own layer.
+ You can start with something in <filename>meta/conf/machine</filename> - <filename>
+ meta/conf/machine/atom-pc.conf</filename> for example. Or, you can start with a machine
+ configuration from any of the BSP layers in the meta-intel repository at
+ <ulink url='http://git.pokylinux.org/cgit/cgit.cgi/meta-intel/'></ulink>, such as
+ <filename>meta-intel/meta-emenlow/conf/machine/emenlow.conf</filename>.
</para>
<para>
- The most up-to-date machines that are probably most similar to yours and that you might want
- to look at are <filename>meta/conf/machine/atom-pc.conf</filename> and
- <filename>meta-emenlow/conf/machine/emenlow.conf</filename>.
- Both of these files were either just added or upgraded to use the Yocto Project kernel
- at <ulink url='http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/'></ulink>.
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.
<para>
As an example consider this:
<itemizedlist>
- <listitem><para>Copy meta-emenlow</para></listitem>
+ <listitem><para>Copy meta-emenlow to meta-mymachine</para></listitem>
<listitem><para>Fix or remove anything you do not need.
For this example the only thing left was the kernel directory with a
- <filename>linux-yocto-stable_git.bbappend</filename> file
- (linux-yocto-stable is the kernel listed in
- <filename>meta-crownbay/conf/machine/crownbay.conf</filename></para></listitem>.
+ <filename>linux-yocto_git.bbappend</filename>
+ file
+ and <filename>meta-mymachine/conf/machine/mymachine.conf</filename>
+ (linux-yocto is the kernel listed in
+ <filename>meta-emenlow/conf/machine/emenlow.conf</filename>)</para></listitem>.
<listitem><para>Add a new entry in the <filename>build/conf/bblayers.conf</filename>
so the new layer can be found by Bitbake.</para></listitem>
</itemizedlist>
</para></listitem>
<listitem><para>
- Get an image with a working kernel built.
+ Create a machine branch for your machine.
</para>
<para>
To create this branch first create a bare clone of the Yocto Project git repository.
Next, create a local clone of that:
<literallayout class='monospaced'>
- $ 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
</literallayout>
</para>
<para>
Now create a branch in the local clone and push it to the bare clone:
<literallayout class='monospaced'>
- $ 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
</literallayout>
- </para>
-
- <para>
- At this point, your git tree should compile.
</para></listitem>
-
+
<listitem><para>
- In a layer, create a <filename>linux-yocto-stable_git.bbappend</filename>
+ In a layer, create a <filename>linux-yocto_git.bbappend</filename>
file with the following:
</para>
<para>
<literallayout class='monospaced'>
- 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"
</literallayout>
</para>
- <para>
- 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.
- </para>
-
<para>
After doing that, select the machine in <filename>build/conf/local.conf</filename>:
<literallayout class='monospaced'>
#
- MACHINE ?= "crownbay"
+ MACHINE ?= "mymachine"
#
</literallayout>
</para>
<literallayout class='monospaced'>
$ bitbake poky-image-sato-live
</literallayout>
+ </para></listitem>
+
+ <listitem><para>
+ Modify the kernel configuration for your machine.
</para>
<para>
And, another <filename>.cfg</filename> file would contain:
<literallayout class='monospaced'>
CONFIG_LOG_BUF_SHIFT=18
+ </literallayout>
- http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/
+ <para>
+ These config fragments could then be picked up and
+ applied to the kernel .config by appending them to the kernel SRC_URI:
+ </para>
- SRC_URI_append_crownbay = " file://some.cfg \
+ <literallayout class='monospaced'>
+ SRC_URI_append_mymachine = " file://some.cfg \
file://other.cfg \
"
</literallayout>
</para>
<para>
- You could also add these directly to the git repository <filename>wrs_meta</filename>
+ You could also add these directly to the git repository <filename>meta</filename>
branch as well.
However, the former method is a simple starting point.
</para></listitem>
<para>
Practically speaking, to generate the patches, you'd go to the source in the build tree:
<literallayout class='monospaced'>
- 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
</literallayout>
</para>
Then, modify the code there, using quilt to save the changes, and recompile until
it works:
<literallayout class='monospaced'>
- $ bitbake -c compile -f linux-yocto-stable
+ $ bitbake -c compile -f linux-yocto
</literallayout>
</para></listitem>
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.
</para></listitem>
</orderedlist>
