summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--documentation/kernel-manual/kernel-how-to.xml124
1 files changed, 65 insertions, 59 deletions
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.
425 425
426 <literallayout class='monospaced'> 426 <literallayout class='monospaced'>
427 # full description of the changes 427 # full description of the changes
428 &gt; git whatchanged &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt; 428 &gt; git whatchanged &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
429 &gt; eg: git whatchanged standard..common_pc-standard 429 &gt; eg: git whatchanged yocto/standard/base..yocto/standard/common-pc/base
430 430
431 # summary of the changes 431 # summary of the changes
432 &gt; git log --pretty=oneline --abbrev-commit &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt; 432 &gt; git log --pretty=oneline --abbrev-commit &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
433 433
434 # source code changes (one combined diff) 434 # source code changes (one combined diff)
435 &gt; git diff &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt; 435 &gt; git diff &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
436 &gt; git show &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt; 436 &gt; git show &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
437 437
438 # dump individual patches per commit 438 # dump individual patches per commit
439 &gt; git format-patch -o &lt;dir&gt; &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt; 439 &gt; git format-patch -o &lt;dir&gt; &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
440 440
441 # determine the change history of a particular file 441 # determine the change history of a particular file
442 &gt; git whatchanged &lt;path to file&gt; 442 &gt; git whatchanged &lt;path to file&gt;
@@ -467,9 +467,9 @@ repository.
467 # determine which branches contain a feature 467 # determine which branches contain a feature
468 &gt; git branch --contains &lt;tag&gt; 468 &gt; git branch --contains &lt;tag&gt;
469 469
470 # show the changes in a kernel type - (0.9 examples) 470 # show the changes in a kernel type
471 &gt; git whatchanged wrs_base..&lt;kernel type&gt; 471 &gt; git whatchanged yocto/base..&lt;kernel type&gt;
472 &gt; eg: git whatchanged wrs_base..standard 472 &gt; eg: git whatchanged yocto/base..yocto/standard/base
473 </literallayout> 473 </literallayout>
474 474
475 <para> 475 <para>
@@ -733,10 +733,10 @@ repository.
733 733
734 <para> 734 <para>
735 For example, the following command pushes the changes from your local branch 735 For example, the following command pushes the changes from your local branch
736 <filename>common_pc-standard</filename> to the remote branch with the same name 736 <filename>yocto/standard/common-pc/base</filename> to the remote branch with the same name
737 in the master repository <filename>//git.mycompany.com/pub/git/kernel-2.6.27</filename>. 737 in the master repository <filename>//git.mycompany.com/pub/git/kernel-2.6.37</filename>.
738 <literallayout class='monospaced'> 738 <literallayout class='monospaced'>
739 &gt; push ssh://git.mycompany.com/pub/git/kernel-2.6.27 common_pc-standard:common_pc-standard 739 &gt; push ssh://git.mycompany.com/pub/git/kernel-2.6.37 yocto/standard/common-pc/base:yocto/standard/common-pc/base
740 </literallayout> 740 </literallayout>
741 </para> 741 </para>
742 742
@@ -866,9 +866,9 @@ repository.
866 866
867 <para> 867 <para>
868 The following commands illustrate some of the steps you could use to 868 The following commands illustrate some of the steps you could use to
869 import the common_pc-standard kernel into a secondary SCM: 869 import the yocto/standard/common-pc/base kernel into a secondary SCM:
870 <literallayout class='monospaced'> 870 <literallayout class='monospaced'>
871 &gt; git checkout common_pc-standard 871 &gt; git checkout yocto/standard/common-pc/base
872 &gt; cd .. ; echo linux/.git &gt; .cvsignore 872 &gt; cd .. ; echo linux/.git &gt; .cvsignore
873 &gt; cvs import -m "initial import" linux MY_COMPANY start 873 &gt; cvs import -m "initial import" linux MY_COMPANY start
874 </literallayout> 874 </literallayout>
@@ -881,8 +881,8 @@ repository.
881 <para> 881 <para>
882 The following commands illustrate how you can condense and merge two BSPs into a second SCM: 882 The following commands illustrate how you can condense and merge two BSPs into a second SCM:
883 <literallayout class='monospaced'> 883 <literallayout class='monospaced'>
884 &gt; git checkout common_pc-standard 884 &gt; git checkout yocto/standard/common-pc/base
885 &gt; git merge common_pc_64-standard 885 &gt; git merge yocto/standard/common-pc-64/base
886 # resolve any conflicts and commit them 886 # resolve any conflicts and commit them
887 &gt; cd .. ; echo linux/.git &gt; .cvsignore 887 &gt; cd .. ; echo linux/.git &gt; .cvsignore
888 &gt; cvs import -m "initial import" linux MY_COMPANY start 888 &gt; cvs import -m "initial import" linux MY_COMPANY start
@@ -1006,9 +1006,12 @@ That's it. Configure and build.
1006 <title>Creating a BSP Based on an Existing Similar BSP</title> 1006 <title>Creating a BSP Based on an Existing Similar BSP</title>
1007 1007
1008 <para> 1008 <para>
1009 This section provides an example for creating a BSP that is based on an existing, and hopefully, 1009 This section provides an example for creating a BSP
1010 similar one. 1010 that is based on an existing, and hopefully, similar
1011 Follow these steps and keep in mind your particular situation and differences: 1011 one. It assumes you will be using a local kernel
1012 repository and will be pointing the kernel recipe at
1013 that. Follow these steps and keep in mind your
1014 particular situation and differences:
1012 1015
1013 <orderedlist> 1016 <orderedlist>
1014 <listitem><para> 1017 <listitem><para>
@@ -1016,16 +1019,14 @@ That's it. Configure and build.
1016 </para> 1019 </para>
1017 1020
1018 <para> 1021 <para>
1019 You can start with something in <filename>meta/conf/machine</filename>. 1022 You can start with something in <filename>meta/conf/machine</filename> - <filename>
1020 Or, <filename>meta-emenlow/conf/machine</filename> has an example in its own layer. 1023 meta/conf/machine/atom-pc.conf</filename> for example. Or, you can start with a machine
1024 configuration from any of the BSP layers in the meta-intel repository at
1025 <ulink url='http://git.pokylinux.org/cgit/cgit.cgi/meta-intel/'></ulink>, such as
1026 <filename>meta-intel/meta-emenlow/conf/machine/emenlow.conf</filename>.
1021 </para> 1027 </para>
1022 1028
1023 <para> 1029 <para>
1024 The most up-to-date machines that are probably most similar to yours and that you might want
1025 to look at are <filename>meta/conf/machine/atom-pc.conf</filename> and
1026 <filename>meta-emenlow/conf/machine/emenlow.conf</filename>.
1027 Both of these files were either just added or upgraded to use the Yocto Project kernel
1028 at <ulink url='http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/'></ulink>.
1029 The main difference between the two is that "emenlow" is in its own layer. 1030 The main difference between the two is that "emenlow" is in its own layer.
1030 It is in its own layer because it needs extra machine-specific packages such as its 1031 It is in its own layer because it needs extra machine-specific packages such as its
1031 own video driver and other supporting packages. 1032 own video driver and other supporting packages.
@@ -1049,19 +1050,21 @@ That's it. Configure and build.
1049 <para> 1050 <para>
1050 As an example consider this: 1051 As an example consider this:
1051 <itemizedlist> 1052 <itemizedlist>
1052 <listitem><para>Copy meta-emenlow</para></listitem> 1053 <listitem><para>Copy meta-emenlow to meta-mymachine</para></listitem>
1053 <listitem><para>Fix or remove anything you do not need. 1054 <listitem><para>Fix or remove anything you do not need.
1054 For this example the only thing left was the kernel directory with a 1055 For this example the only thing left was the kernel directory with a
1055 <filename>linux-yocto-stable_git.bbappend</filename> file 1056 <filename>linux-yocto_git.bbappend</filename>
1056 (linux-yocto-stable is the kernel listed in 1057 file
1057 <filename>meta-crownbay/conf/machine/crownbay.conf</filename></para></listitem>. 1058 and <filename>meta-mymachine/conf/machine/mymachine.conf</filename>
1059 (linux-yocto is the kernel listed in
1060 <filename>meta-emenlow/conf/machine/emenlow.conf</filename>)</para></listitem>.
1058 <listitem><para>Add a new entry in the <filename>build/conf/bblayers.conf</filename> 1061 <listitem><para>Add a new entry in the <filename>build/conf/bblayers.conf</filename>
1059 so the new layer can be found by Bitbake.</para></listitem> 1062 so the new layer can be found by Bitbake.</para></listitem>
1060 </itemizedlist> 1063 </itemizedlist>
1061 </para></listitem> 1064 </para></listitem>
1062 1065
1063 <listitem><para> 1066 <listitem><para>
1064 Get an image with a working kernel built. 1067 Create a machine branch for your machine.
1065 </para> 1068 </para>
1066 1069
1067 <para> 1070 <para>
@@ -1070,58 +1073,52 @@ That's it. Configure and build.
1070 To create this branch first create a bare clone of the Yocto Project git repository. 1073 To create this branch first create a bare clone of the Yocto Project git repository.
1071 Next, create a local clone of that: 1074 Next, create a local clone of that:
1072 <literallayout class='monospaced'> 1075 <literallayout class='monospaced'>
1073 $ git clone --bare git://git.pokylinux.org/linux-2.6-windriver.git 1076 $ git clone --bare git://git.pokylinux.org/linux-yocto-2.6.37.git
1074 linux-2.6-windriver.git 1077 linux-yocto-2.6.37.git
1075 $ git clone linux-2.6-windriver.git linux-2.6-windriver 1078 $ git clone linux-yocto-2.6.37.git linux-yocto-2.6.37
1076 </literallayout> 1079 </literallayout>
1077 </para> 1080 </para>
1078 1081
1079 <para> 1082 <para>
1080 Now create a branch in the local clone and push it to the bare clone: 1083 Now create a branch in the local clone and push it to the bare clone:
1081 <literallayout class='monospaced'> 1084 <literallayout class='monospaced'>
1082 $ git checkout -b crownbay-standard origin/standard 1085 $ git checkout -b yocto/standard/mymachine origin/yocto/standard/base
1083 $ git push origin crownbay-standard:crownbay-standard 1086 $ git push origin yocto/standard/mymachine:yocto/standard/mymachine
1084 </literallayout> 1087 </literallayout>
1085 </para>
1086
1087 <para>
1088 At this point, your git tree should compile.
1089 </para></listitem> 1088 </para></listitem>
1090 1089
1091 <listitem><para> 1090 <listitem><para>
1092 In a layer, create a <filename>linux-yocto-stable_git.bbappend</filename> 1091 In a layer, create a <filename>linux-yocto_git.bbappend</filename>
1093 file with the following: 1092 file with the following:
1094 </para> 1093 </para>
1095 1094
1096 <para> 1095 <para>
1097 <literallayout class='monospaced'> 1096 <literallayout class='monospaced'>
1098 COMPATIBLE_MACHINE = ${MACHINE} 1097 FILESEXTRAPATHS := "${THISDIR}/${PN}"
1098 COMPATIBLE_MACHINE_mymachine = "mymachine"
1099 1099
1100 # It is often nice to have a local clone of the kernel repository, to 1100 # It is often nice to have a local clone of the kernel repository, to
1101 # allow patches to be staged, branches created, and so forth. Modify 1101 # allow patches to be staged, branches created, and so forth. Modify
1102 # KSRC to point to your local clone as appropriate. 1102 # KSRC to point to your local clone as appropriate.
1103 1103
1104 # KSRC ?= /path/to/your/bare/clone/yocto-kernel 1104 KSRC ?= /path/to/your/bare/clone/for/example/linux-yocto-2.6.37.git
1105 1105
1106 # KMACHINE is the branch to be built, or alternateively 1106 # KMACHINE is the branch to be built, or alternatively
1107 # KBRANCH can be directly set. 1107 # KBRANCH can be directly set.
1108 # KBRANCH is set to KMACHINE in the main linux-yocto_git.bb
1109 # KBRANCH ?= "${LINUX_KERNEL_TYPE}/${KMACHINE}"
1108 1110
1109 # KBRANCH ?= "${KMACHINE}-${LINUX_KERNEL_TYPE}" 1111 KMACHINE_mymachine = "yocto/standard/mymachine"
1110 1112
1111 # SRC_URI = "git://${KSRC};nocheckout=1;branch=${KBRANCH},meta;name=machine,meta" 1113 SRC_URI = "git://${KSRC};nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
1112 </literallayout> 1114 </literallayout>
1113 </para> 1115 </para>
1114 1116
1115 <para> 1117 <para>
1116 In the previous sample file you need to update and remove the comment from
1117 the KSRC assignment and also remove the comment from the SRC_URI line.
1118 </para>
1119
1120 <para>
1121 After doing that, select the machine in <filename>build/conf/local.conf</filename>: 1118 After doing that, select the machine in <filename>build/conf/local.conf</filename>:
1122 <literallayout class='monospaced'> 1119 <literallayout class='monospaced'>
1123 # 1120 #
1124 MACHINE ?= "crownbay" 1121 MACHINE ?= "mymachine"
1125 # 1122 #
1126 </literallayout> 1123 </literallayout>
1127 </para> 1124 </para>
@@ -1131,6 +1128,10 @@ That's it. Configure and build.
1131 <literallayout class='monospaced'> 1128 <literallayout class='monospaced'>
1132 $ bitbake poky-image-sato-live 1129 $ bitbake poky-image-sato-live
1133 </literallayout> 1130 </literallayout>
1131 </para></listitem>
1132
1133 <listitem><para>
1134 Modify the kernel configuration for your machine.
1134 </para> 1135 </para>
1135 1136
1136 <para> 1137 <para>
@@ -1149,17 +1150,22 @@ That's it. Configure and build.
1149 And, another <filename>.cfg</filename> file would contain: 1150 And, another <filename>.cfg</filename> file would contain:
1150 <literallayout class='monospaced'> 1151 <literallayout class='monospaced'>
1151 CONFIG_LOG_BUF_SHIFT=18 1152 CONFIG_LOG_BUF_SHIFT=18
1153 </literallayout>
1152 1154
1153 http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/ 1155 <para>
1156 These config fragments could then be picked up and
1157 applied to the kernel .config by appending them to the kernel SRC_URI:
1158 </para>
1154 1159
1155 SRC_URI_append_crownbay = " file://some.cfg \ 1160 <literallayout class='monospaced'>
1161 SRC_URI_append_mymachine = " file://some.cfg \
1156 file://other.cfg \ 1162 file://other.cfg \
1157 " 1163 "
1158 </literallayout> 1164 </literallayout>
1159 </para> 1165 </para>
1160 1166
1161 <para> 1167 <para>
1162 You could also add these directly to the git repository <filename>wrs_meta</filename> 1168 You could also add these directly to the git repository <filename>meta</filename>
1163 branch as well. 1169 branch as well.
1164 However, the former method is a simple starting point. 1170 However, the former method is a simple starting point.
1165 </para></listitem> 1171 </para></listitem>
@@ -1173,7 +1179,7 @@ That's it. Configure and build.
1173 <para> 1179 <para>
1174 Practically speaking, to generate the patches, you'd go to the source in the build tree: 1180 Practically speaking, to generate the patches, you'd go to the source in the build tree:
1175 <literallayout class='monospaced'> 1181 <literallayout class='monospaced'>
1176 build/tmp/work/crownbay-poky-linux/linux-yocto-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+ 1182 build/tmp/work/mymachine-poky-linux/linux-yocto-2.6.37+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+
11770431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux 11830431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux
1178 </literallayout> 1184 </literallayout>
1179 </para> 1185 </para>
@@ -1182,7 +1188,7 @@ That's it. Configure and build.
1182 Then, modify the code there, using quilt to save the changes, and recompile until 1188 Then, modify the code there, using quilt to save the changes, and recompile until
1183 it works: 1189 it works:
1184 <literallayout class='monospaced'> 1190 <literallayout class='monospaced'>
1185 $ bitbake -c compile -f linux-yocto-stable 1191 $ bitbake -c compile -f linux-yocto
1186 </literallayout> 1192 </literallayout>
1187 </para></listitem> 1193 </para></listitem>
1188 1194
@@ -1191,7 +1197,7 @@ That's it. Configure and build.
1191 SRC_URI location. 1197 SRC_URI location.
1192 The patch is applied the next time you do a clean build. 1198 The patch is applied the next time you do a clean build.
1193 Of course, since you have a branch for the BSP in git, it would be better to put it there instead. 1199 Of course, since you have a branch for the BSP in git, it would be better to put it there instead.
1194 For example, in this case, commit the patch to the "crownbay-standard" branch, and during the 1200 For example, in this case, commit the patch to the "yocto/standard/mymachine" branch, and during the
1195 next build it is applied from there. 1201 next build it is applied from there.
1196 </para></listitem> 1202 </para></listitem>
1197 </orderedlist> 1203 </orderedlist>