summaryrefslogtreecommitdiffstats
path: root/documentation/kernel-manual/kernel-how-to.xml
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2010-12-01 07:09:10 -0800
committerSaul Wold <Saul.Wold@intel.com>2010-12-10 22:01:20 -0800
commitddbd172dd8b80dad5f32b801ba9785775030d153 (patch)
tree6c461fd3e552017d8909b38ec4743f1dd44bdca1 /documentation/kernel-manual/kernel-how-to.xml
parent5bda926c80d825470ac3ba72f3682b469308dcad (diff)
downloadpoky-ddbd172dd8b80dad5f32b801ba9785775030d153.tar.gz
documentation/kernel-manual/kernel-how-to.xml: Completed scrub to the text.
This version represents the completed first draft with all of Bruce Ashfield's comments applied and a good scrubbing of the text. Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Diffstat (limited to 'documentation/kernel-manual/kernel-how-to.xml')
-rw-r--r--documentation/kernel-manual/kernel-how-to.xml525
1 files changed, 302 insertions, 223 deletions
diff --git a/documentation/kernel-manual/kernel-how-to.xml b/documentation/kernel-manual/kernel-how-to.xml
index d32ea20b34..25b4282416 100644
--- a/documentation/kernel-manual/kernel-how-to.xml
+++ b/documentation/kernel-manual/kernel-how-to.xml
@@ -761,40 +761,46 @@ repository.
761 </section> 761 </section>
762 762
763 <section id='export-for-external-upstream-submission'> 763 <section id='export-for-external-upstream-submission'>
764 <title>Export for External (Upstream) Submission</title> 764 <title>Exporting Changes for External (Upstream) Submission</title>
765<para> 765
766If patches are to be sent for external submission, they can be done via a 766 <para>
767pull request if the patch series is large or the maintainer prefers to pull 767 This section describes how to export changes for external upstream submission.
768changes. But commonly, patches are sent as email series for easy review and 768 If the patch series is large or the maintainer prefers to pull
769integration. 769 changes, you can submit these changes by using a pull request.
770</para> 770 However, it is common to sent patches as an email series.
771<note><para> 771 This method allows easy review and integration of the changes.
772Before sending patches for review ensure that you understand the 772 </para>
773standard of the community in question and follow their best practices. For 773
774example, kernel patches should follow standards such as: 774 <note><para>
775<itemizedlist> 775 Before sending patches for review be sure you understand the
776 <listitem><para><ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem> 776 community standards for submitting and documenting changes and follow their best practices.
777 <listitem><para><ulink url='http://linux.yyz.us/patch-format.html'></ulink></para></listitem> 777 For example, kernel patches should follow standards such as:
778 <listitem><para>Documentation/SubmittingPatches (in any linux kernel source tree)</para></listitem> 778 <itemizedlist>
779</itemizedlist> 779 <listitem><para><ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem>
780</para></note> 780 <listitem><para><ulink url='http://linux.yyz.us/patch-format.html'></ulink></para></listitem>
781<para> 781 <listitem><para>Documentation/SubmittingPatches (in any linux kernel source tree)</para></listitem>
782The messages used to commit changes are a large part of these standards, so 782 </itemizedlist>
783ensure that the headers for each commit have the required information. If the 783 </para></note>
784initial commits were not properly documented or don't meet those standards 784
785rebasing via git rebase -i offer an opportunity to manipulate the commits and 785 <para>
786get them into the required format. Other techniques such as branching and 786 The messages used to commit changes are a large part of these standards.
787cherry picking commits are also viable options. 787 Consequently, be sure that the headers for each commit have the required information.
788</para> 788 If the initial commits were not properly documented or do not meet those standards,
789<para> 789 you can re-base by using the "git rebase -i" command to manipulate the commits and
790Once complete, patches are sent via email to the maintainer(s) or lists that 790 get them into the required format.
791review and integrate changes. "git send-email" is commonly used to ensure 791 Other techniques such as branching and cherry-picking commits are also viable options.
792that patches are properly formatted for easy application and avoid mailer 792 </para>
793induced patch damage. 793
794</para> 794 <para>
795<para> 795 Once you complete the commits, you can generate the email that sends the patches
796An example of dumping patches for external submission follows: 796 to the maintainer(s) or lists that review and integrate changes.
797<literallayout class='monospaced'> 797 The command "git send-email" is commonly used to ensure that patches are properly
798 formatted for easy application and avoid mailer-induced patch damage.
799 </para>
800
801 <para>
802 The following is an example of dumping patches for external submission:
803 <literallayout class='monospaced'>
798 # dump the last 4 commits 804 # dump the last 4 commits
799 &gt; git format-patch --thread -n -o ~/rr/ HEAD^^^^ 805 &gt; git format-patch --thread -n -o ~/rr/ HEAD^^^^
800 &gt; git send-email --compose --subject '[RFC 0/N] &lt;patch series summary&gt;' \ 806 &gt; git send-email --compose --subject '[RFC 0/N] &lt;patch series summary&gt;' \
@@ -802,88 +808,98 @@ An example of dumping patches for external submission follows:
802 --cc list@yoctoproject.org ~/rr 808 --cc list@yoctoproject.org ~/rr
803 # the editor is invoked for the 0/N patch, and when complete the entire 809 # the editor is invoked for the 0/N patch, and when complete the entire
804 # series is sent via email for review 810 # series is sent via email for review
805</literallayout> 811 </literallayout>
806</para> 812 </para>
807 </section> 813 </section>
808 814
809 <section id='export-for-import-into-other-scm'> 815 <section id='export-for-import-into-other-scm'>
810 <title>Export for Import into Other SCM</title> 816 <title>Exporting Changes for Import into Another SCM</title>
811<para> 817
812Using any one of the previously discussed techniques, commits can be exported 818 <para>
813as patches for import into another SCM. Note however, that if those patches 819 When you want to export changes for import into another
814are manually applied to a secondary tree and then that secondary tree is 820 Source Code Manager (SCM) you can use any of the previously discussed
815checked into the SCM, then it often results in lost information (like commit 821 techniques.
816logs) and so it is not recommended. 822 However, if the patches are manually applied to a secondary tree and then
817</para> 823 that tree is checked into the SCM you can lose change information such as
818<para> 824 commit logs.
819Many SCMs can directly import git commits, or can translate git patches to 825 Yocto Project does not recommend this process.
820not lose information. Those facilities are SCM dependent and should be used 826 </para>
821whenever possible. 827
822</para> 828 <para>
829 Many SCMs can directly import git commits, or can translate git patches so that
830 information is not lost.
831 Those facilities are SCM-dependent and you should use them whenever possible.
832 </para>
823 </section> 833 </section>
824 </section> 834 </section>
825 835
826 <section id='scm-working-with-the-yocto-project-kernel-in-another-scm'> 836 <section id='scm-working-with-the-yocto-project-kernel-in-another-scm'>
827 <title>SCM: Working with the Yocto Project Kernel in Another SCM</title> 837 <title>Working with the Yocto Project Kernel in Another SCM</title>
828<para> 838
829This is not the same as the exporting of patches to another SCM, but instead 839 <para>
830is concerned with kernel development that is done completely in another 840 This section describes kernel development in another SCM, which is not the same
831environment, but built with the Yocto Project build system. In this scenario two 841 as exporting changes to another SCM.
832things must happen: 842 For this scenario you use the Yocto Project build system to
833<itemizedlist> 843 develop the kernel in a different SCM.
834 <listitem><para>The delivered Yocto Project kernel must be exported into the second 844 The following must be true for you to accomplish this:
835 SCM.</para></listitem> 845 <itemizedlist>
836 <listitem><para>Development must be exported from that secondary SCM into a 846 <listitem><para>The delivered Yocto Project kernel must be exported into the second
837 format that can be used by the Yocto Project build system.</para></listitem> 847 SCM.</para></listitem>
838</itemizedlist> 848 <listitem><para>Development must be exported from that secondary SCM into a
839</para> 849 format that can be used by the Yocto Project build system.</para></listitem>
850 </itemizedlist>
851 </para>
852
840 <section id='exporting-delivered-kernel-to-scm'> 853 <section id='exporting-delivered-kernel-to-scm'>
841 <title>Exporting Delivered Kernel to SCM</title> 854 <title>Exporting the Delivered Kernel to the SCM</title>
842<para> 855
843Depending on the SCM it may be possible to export the entire Yocto Project 856 <para>
844kernel git repository, branches and all, into a new environment. This is the 857 Depending on the SCM it might be possible to export the entire Yocto Project
845preferred method, since it has the most flexibility and potential to maintain 858 kernel git repository, branches and all, into a new environment.
846the meta data associated with each commit. 859 This method is preferred because it has the most flexibility and potential to maintain
847</para> 860 the meta data associated with each commit.
848<para> 861 </para>
849When a direct import mechanism is not available, it is still possible to 862
850export a branch (or series of branches) and check them into a new 863 <para>
851repository. 864 When a direct import mechanism is not available, it is still possible to
852</para> 865 export a branch (or series of branches) and check them into a new repository.
853<para> 866 </para>
854The following commands illustrate some of the steps that could be used to 867
855import the common_pc-standard kernel into a secondary SCM 868 <para>
856<literallayout class='monospaced'> 869 The following commands illustrate some of the steps you could use to
870 import the common_pc-standard kernel into a secondary SCM:
871 <literallayout class='monospaced'>
857 &gt; git checkout common_pc-standard 872 &gt; git checkout common_pc-standard
858 &gt; cd .. ; echo linux/.git &gt; .cvsignore 873 &gt; cd .. ; echo linux/.git &gt; .cvsignore
859 &gt; cvs import -m "initial import" linux MY_COMPANY start 874 &gt; cvs import -m "initial import" linux MY_COMPANY start
860</literallayout> 875 </literallayout>
861The CVS repo could now be relocated and used in a centralized manner. 876 </para>
862</para> 877
863<para> 878 <para>
864The following commands illustrate how two BSPs could be condensed and merged 879 You could now relocate the CVS repository and use it in a centralized manner.
865into a second SCM: 880 </para>
866<literallayout class='monospaced'> 881
882 <para>
883 The following commands illustrate how you can condense and merge two BSPs into a second SCM:
884 <literallayout class='monospaced'>
867 &gt; git checkout common_pc-standard 885 &gt; git checkout common_pc-standard
868 &gt; git merge cav_ebt5800-standard 886 &gt; git merge cav_ebt5800-standard
869 # resolve any conflicts and commit them 887 # resolve any conflicts and commit them
870 &gt; cd .. ; echo linux/.git &gt; .cvsignore 888 &gt; cd .. ; echo linux/.git &gt; .cvsignore
871 &gt; cvs import -m "initial import" linux MY_COMPANY start 889 &gt; cvs import -m "initial import" linux MY_COMPANY start
872</literallayout> 890 </literallayout>
873</para> 891 </para>
874 </section> 892 </section>
875 893
876 <section id='importing-changes-for-build'> 894 <section id='importing-changes-for-build'>
877 <title>Importing Changes for Build</title> 895 <title>Importing Changes for the Build</title>
878<para> 896
879Once development has reached a suitable point in the second development 897 <para>
880environment, changes can either be exported as patches or imported into git 898 Once development has reached a suitable point in the second development
881directly (if a conversion/import mechanism is available for the SCM). 899 environment, you need to export the changes as patches.
882</para> 900 To export them place the changes in a recipe and
883<para> 901 automatically apply them to the kernel during patching.
884If changes are exported as patches, they can be placed in a recipe and 902 </para>
885automatically applied to the kernel during patching.
886</para>
887<!--<para> 903<!--<para>
888If changes are imported directly into git, they must be propagated to the 904If changes are imported directly into git, they must be propagated to the
889wrll-linux-2.6.27/git/default_kernel bare clone of each individual build 905wrll-linux-2.6.27/git/default_kernel bare clone of each individual build
@@ -988,97 +1004,139 @@ That's it. Configure and build.
988 1004
989 1005
990 <section id='bsp-creating'> 1006 <section id='bsp-creating'>
991 <title>BSP: Creating</title> 1007 <title>Creating a BSP Based on an Existing Similar BSP</title>
1008
992 <para> 1009 <para>
993 This section provides an example for creating a BSP based on an existing, and hopefully, 1010 This section provides an example for creating a BSP that is based on an existing, and hopefully,
994 similar one. 1011 similar one.
995 Follow these steps and keep in mind your particular situation and differences: 1012 Follow these steps and keep in mind your particular situation and differences:
1013
996 <orderedlist> 1014 <orderedlist>
997 <listitem><para>Get a machine configuration file that matches your machine.</para> 1015 <listitem><para>
998 <para>You can start with something in <filename>meta/conf/machine</filename>. 1016 Identify a machine configuration file that matches your machine.
999 Or, <filename>meta-emenlow/conf/machine</filename> has an example in its own layer.</para> 1017 </para>
1000 <para>The most up-to-date machines that are probably most similar to yours and that you might want 1018
1001 to look at are <filename>meta/conf/machine/atom-pc.conf</filename> and 1019 <para>
1002 <filename>meta-emenlow/conf/machine/emenlow.conf</filename>. 1020 You can start with something in <filename>meta/conf/machine</filename>.
1003 Both of these were either just added or upgraded to use the Yocto Project kernel 1021 Or, <filename>meta-emenlow/conf/machine</filename> has an example in its own layer.
1004 at <ulink url='http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/'></ulink>. 1022 </para>
1005 The main difference between them is that "emenlow" is in its own layer. 1023
1006 It is in its own layer because it needs extra machine-specific packages such as its 1024 <para>
1007 own video driver and other supporting packages. 1025 The most up-to-date machines that are probably most similar to yours and that you might want
1008 The "atom-pc" is simpler and does not need any special packages - everything it needs can 1026 to look at are <filename>meta/conf/machine/atom-pc.conf</filename> and
1009 be specified in the configuration file. 1027 <filename>meta-emenlow/conf/machine/emenlow.conf</filename>.
1010 The "atom-pc" machine also supports all of Asus eee901, Acer Aspire One, Toshiba NB305, 1028 Both of these files were either just added or upgraded to use the Yocto Project kernel
1011 and the Intel&reg; Embedded Development Board 1-N450 with no changes.</para> 1029 at <ulink url='http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/'></ulink>.
1012 <para>If you want to make minor changes to support a slightly different machine, you can 1030 The main difference between the two is that "emenlow" is in its own layer.
1013 create a new configuration file for it and add it alongside the others. 1031 It is in its own layer because it needs extra machine-specific packages such as its
1014 You might consider keeping the common stuff separate and including it.</para> 1032 own video driver and other supporting packages.
1015 <para>Similarly, you can also use multiple configuration files for different machines even 1033 The "atom-pc" is simpler and does not need any special packages - everything it needs can
1016 if you do it as a separate layer like meta-emenlow.</para> 1034 be specified in the configuration file.
1017 <para>As an example consider this: 1035 The "atom-pc" machine also supports all of Asus eee901, Acer Aspire One, Toshiba NB305,
1018 <itemizedlist> 1036 and the Intel&reg; Embedded Development Board 1-N450 with no changes.
1019 <listitem><para>Copy meta-emenlow</para></listitem> 1037 </para>
1020 <listitem><para>Fix or remove anything you do not need. 1038
1021 For this example the only thing left was the kernel directory with a linux-yocto_git.bbappend 1039 <para>
1022 file (linux-yocto is the kernel listed in 1040 If you want to make minor changes to support a slightly different machine, you can
1023 <filename>meta-crownbay/conf/machine/crownbay.conf</filename>. 1041 create a new configuration file for it and add it alongside the others.
1024 Finally, a new entry to the <filename>build/donf/bblayers.conf</filename> was added so the 1042 You might consider keeping the common information separate and including it.
1025 new layer could be found by Bitbake.</para></listitem> 1043 </para>
1026 </itemizedlist> 1044
1045 <para>
1046 Similarly, you can also use multiple configuration files for different machines even
1047 if you do it as a separate layer like meta-emenlow.
1048 </para>
1049
1050 <para>
1051 As an example consider this:
1052 <itemizedlist>
1053 <listitem><para>Copy meta-emenlow</para></listitem>
1054 <listitem><para>Fix or remove anything you do not need.
1055 For this example the only thing left was the kernel directory with a
1056 <filename>linux-yocto_git.bbappend</filename> file (linux-yocto is the kernel listed in
1057 <filename>meta-crownbay/conf/machine/crownbay.conf</filename></para></listitem>.
1058 <listitem><para>Add a new entry in the <filename>build/donf/bblayers.conf</filename>
1059 so the new layer can be found by Bitbake.</para></listitem>
1060 </itemizedlist>
1027 </para></listitem> 1061 </para></listitem>
1028 <listitem><para>Get an image with a working kernel built.</para> 1062
1029 <para>For the kernel to compile successfully, you need to create a branch in the git repository 1063 <listitem><para>
1030 specifically named for your machine. 1064 Get an image with a working kernel built.
1031 So first create a bare clone of the Yocto Project git repository, and then create a 1065 </para>
1032 local clone of that: 1066
1033 <literallayout class='monospaced'> 1067 <para>
1068 For the kernel to compile successfully, you need to create a branch in the git repository
1069 specifically named for your machine.
1070 To create this branch first create a bare clone of the Yocto Project git repository.
1071 Next, create a local clone of that:
1072 <literallayout class='monospaced'>
1034 $ git clone --bare git://git.pokylinux.org/linux-2.6-windriver.git 1073 $ git clone --bare git://git.pokylinux.org/linux-2.6-windriver.git
1035 linux-2.6-windriver.git 1074 linux-2.6-windriver.git
1036 $ git clone linux-2.6-windriver.git linux-2.6-windriver 1075 $ git clone linux-2.6-windriver.git linux-2.6-windriver
1037 </literallayout> 1076 </literallayout>
1038 </para> 1077 </para>
1039 <para>Now create a branch in the local clone and push it to the bare clone: 1078
1040 <literallayout class='monospaced'> 1079 <para>
1080 Now create a branch in the local clone and push it to the bare clone:
1081 <literallayout class='monospaced'>
1041 $ git checkout -b crownbay-standard origin/standard $ git push origin crownbay-standard:crownbay-standard 1082 $ git checkout -b crownbay-standard origin/standard $ git push origin crownbay-standard:crownbay-standard
1042 </literallayout> 1083 </literallayout>
1043 </para> 1084 </para>
1044 <para>At this point, your git tree should be set up well enough to compile.</para></listitem> 1085
1045 <listitem><para>Point the build at the new kernel git tree.</para> 1086 <para>
1046 <para>You can do this by commenting out the SRC_URI variable in 1087 At this point, your git tree should compile.
1047 <filename>meta/recipes-kernel/linux/linux-yocto_git.bb</filename> and using a SRC_URI 1088 </para></listitem>
1048 that points to your new bare git tree. 1089
1049 You should also be able to do this in <filename>linux-yocto_git.bbappend</filename> in the layer: 1090 <listitem><para>
1050 <literallayout class='monospaced'> 1091 Point the build at the new kernel git tree.
1092 </para>
1093
1094 <para>
1095 You can do this by commenting out the SRC_URI variable in
1096 <filename>meta/recipes-kernel/linux/linux-yocto_git.bb</filename> and using a SRC_URI
1097 that points to your new bare git tree.
1098 You should also be able to do this in <filename>linux-yocto_git.bbappend</filename> in the layer:
1099 <literallayout class='monospaced'>
1051 # To use a staged, on-disk bare clone of a Wind River Kernel, use a variant of the 1100 # To use a staged, on-disk bare clone of a Wind River Kernel, use a variant of the
1052 # below SRC_URI = "git://///path/to/kernel/default_kernel.git;fullclone=1" 1101 # below SRC_URI = "git://///path/to/kernel/default_kernel.git;fullclone=1"
1053 # 1102 #
1054 SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine 1103 SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine
1055\ 1104\
1056 git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta" 1105 git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"
1057 </literallayout> 1106 </literallayout>
1058 </para> 1107 </para>
1059 <para>After doing that, select the machine in <filename>build/conf/local.conf</filename>: 1108
1060 <literallayout class='monospaced'> 1109 <para>
1110 After doing that, select the machine in <filename>build/conf/local.conf</filename>:
1111 <literallayout class='monospaced'>
1061 # 1112 #
1062 MACHINE ?= "crownbay" 1113 MACHINE ?= "crownbay"
1063 # 1114 #
1064 </literallayout> 1115 </literallayout>
1065 </para> 1116 </para>
1066 <para>You should now be able to build and boot an image with the new kernel: 1117
1067 <literallayout class='monospaced'> 1118 <para>
1119 You should now be able to build and boot an image with the new kernel:
1120 <literallayout class='monospaced'>
1068 $ bitbake poky-image-sato-live 1121 $ bitbake poky-image-sato-live
1069 </literallayout> 1122 </literallayout>
1070 </para> 1123 </para>
1071 <para>Of course, that will give you a kernel with the default config, which is probably 1124
1072 not what you want. 1125 <para>
1073 If you just want to set some kernel config options, you can do that by putting them in a files. 1126 Of course, that will give you a kernel with the default configuration file, which is probably
1074 For example inserting the following into some <filename>.cfg</filename> file: 1127 not what you want.
1075 <literallayout class='monospaced'> 1128 If you just want to set some kernel configuration options, you can do that by
1129 putting them in a file.
1130 For example, inserting the following into some <filename>.cfg</filename> file:
1131 <literallayout class='monospaced'>
1076 CONFIG_NETDEV_1000=y 1132 CONFIG_NETDEV_1000=y
1077 CONFIG_E1000E=y 1133 CONFIG_E1000E=y
1078 </literallayout> 1134 </literallayout>
1079 </para> 1135 </para>
1080 <para>And, another <filename>.cfg</filename> file would contain: 1136
1081 <literallayout class='monospaced'> 1137 <para>
1138 And, another <filename>.cfg</filename> file would contain:
1139 <literallayout class='monospaced'>
1082 CONFIG_LOG_BUF_SHIFT=18 1140 CONFIG_LOG_BUF_SHIFT=18
1083 1141
1084 http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/ 1142 http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/
@@ -1086,38 +1144,50 @@ That's it. Configure and build.
1086 SRC_URI_append_crownbay = " file://some.cfg \ 1144 SRC_URI_append_crownbay = " file://some.cfg \
1087 file://other.cfg \ 1145 file://other.cfg \
1088 " 1146 "
1089 </literallayout> 1147 </literallayout>
1090 </para> 1148 </para>
1091 <para>You could also add these directly to the git repo's wrs_meta branch as well. 1149
1092 However, the former method is probably easier.</para></listitem> 1150 <para>
1093 <listitem><para>If you're also adding patches to the kernel, you can do the same thing. 1151 You could also add these directly to the git repository <filename>wrs_meta</filename>
1094 Put your patches in the SRC_URI as well (plus .cfg for their kernel config options if needed).</para> 1152 branch as well.
1095 <para>Practically speaking, to generate the patches, you'd go to the source in the build tree: 1153 However, the former method is probably easier.
1096 <literallayout class='monospaced'> 1154 </para></listitem>
1155
1156 <listitem><para>
1157 If you're also adding patches to the kernel, you can do the same thing.
1158 Put your patches in the SRC_URI as well (plus <filename>.cfg</filename> for their kernel
1159 configuration options if needed).
1160 </para>
1161
1162 <para>
1163 Practically speaking, to generate the patches, you'd go to the source in the build tree:
1164 <literallayout class='monospaced'>
1097 build/tmp/work/crownbay-poky-linux/linux-yocto-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+ 1165 build/tmp/work/crownbay-poky-linux/linux-yocto-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+
10980431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux 11660431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux
1099 </literallayout> 1167 </literallayout>
1100 </para> 1168 </para>
1101 <para>Then, modify the code there, using quilt to save the changes, and recompile 1169
1102 (bitbake -c compile -f) 1170 <para>
1103 until it works.</para></listitem> 1171 Then, modify the code there, using quilt to save the changes, and recompile until
1104 <listitem><para>Once you have the final patch from quilt, copy it to the 1172 it works:
1105 SRC_URI location, and it should be 1173 <literallayout class='monospaced'>
1106 applied the next time you do a clean build. 1174 $ bitbake -c compile -f
1107 Of course, since you have a branch for the BSP in git, it would be better to put it there instead. 1175 </literallayout>
1108 For example, in this case, commit the patch to the crownbay-standard branch, and during the 1176 </para></listitem>
1109 next build it will be applied from there.</para></listitem> 1177
1178 <listitem><para>
1179 Once you have the final patch from quilt, copy it to the
1180 SRC_URI location.
1181 The patch is applied the next time you do a clean build.
1182 Of course, since you have a branch for the BSP in git, it would be better to put it there instead.
1183 For example, in this case, commit the patch to the "crownbay-standard" branch, and during the
1184 next build it is applied from there.
1185 </para></listitem>
1110 </orderedlist> 1186 </orderedlist>
1111 </para> 1187 </para>
1112 </section> 1188 </section>
1113 1189
1114 1190
1115
1116
1117
1118
1119
1120
1121<!-- <section id='bsp-creating-a-new-bsp'> 1191<!-- <section id='bsp-creating-a-new-bsp'>
1122 <title>BSP: Creating a New BSP</title> 1192 <title>BSP: Creating a New BSP</title>
1123<para> 1193<para>
@@ -1825,51 +1895,60 @@ This section shows an example of transforms:
1825 1895
1826 <section id='tip-dirty-string'> 1896 <section id='tip-dirty-string'>
1827 <title>"-dirty" String</title> 1897 <title>"-dirty" String</title>
1828<para> 1898
1829If kernel images are being built with -dirty on the end of the version 1899 <para>
1830string, this simply means that there are modification in the source 1900 If kernel images are being built with "-dirty" on the end of the version
1831directory that haven't been committed. 1901 string, this simply means that modifications in the source
1832<literallayout class='monospaced'> 1902 directory have not been committed.
1903 <literallayout class='monospaced'>
1833 &gt; git status 1904 &gt; git status
1834</literallayout> 1905 </literallayout>
1835</para> 1906 </para>
1836<para> 1907
1837The above git command will indicate modified, removed or added files. Those changes should 1908 <para>
1838be committed to the tree (even if they will never be saved, or exported 1909 You can use the git command above to report modified, removed, or added files.
1839for future use) and the kernel rebuilt. 1910 You should commit those changes to the tree regardless of whether they will be saved,
1840</para> 1911 exported, or used.
1841<para> 1912 Once you commit the changes you need to rebuild the kernel.
1842To brute force pickup and commit all such pending changes enter the following: 1913 </para>
1843<literallayout class='monospaced'> 1914
1915 <para>
1916 To brute force pickup and commit all such pending changes enter the following:
1917 <literallayout class='monospaced'>
1844 &gt; git add . 1918 &gt; git add .
1845 &gt; git commit -s -a -m "getting rid of -dirty" 1919 &gt; git commit -s -a -m "getting rid of -dirty"
1846</literallayout> 1920 </literallayout>
1847</para> 1921 </para>
1848<para> 1922
1849And then rebuild the kernel 1923 <para>
1850</para> 1924 Next, rebuild the kernel.
1925 </para>
1851 </section> 1926 </section>
1852 1927
1853 <section id='kernel-transition-kernel-layer'> 1928 <section id='kernel-transition-kernel-layer'>
1854 <title>Kernel: Transition Kernel Layer</title> 1929 <title>Creating a Transition Kernel Layer</title>
1855<para> 1930
1856In order to temporarily use a different base kernel in Yocto Project 1931 <para>
1857Linux 3.0 you need to do the following: 1932 You can temporarily use a different base kernel in Yocto Project by doing the following:
1858<orderedlist> 1933
1859 <listitem><para>Create a custom kernel layer.</para></listitem> 1934 <orderedlist>
1860 <listitem><para>Create a git repository of the transition kernel.</para></listitem> 1935 <listitem><para>Create a custom kernel layer.</para></listitem>
1861</orderedlist> 1936 <listitem><para>Create a git repository of the transition kernel.</para></listitem>
1862</para> 1937 </orderedlist>
1863<para> 1938 </para>
1864Once those requirements are met multiple boards and kernels can 1939
1865be built. The cost of setup is only paid once and then additional 1940 <para>
1866BSPs and options can be added. 1941 Once you meet those requirements you can build multiple boards and kernels.
1867</para> 1942 You pay the setup cost only once.
1868<para> 1943 You can then add additional BSPs and options.
1869This creates a transition kernel layer to evaluate functionality 1944 </para>
1870of some other kernel with the goal of easing transition to an 1945
1871integrated and validated Yocto Project kernel. 1946 <para>
1872</para> 1947 Once you have the transition kernel layer in place you can evaluate
1948 another kernel's functionality with the goal of easing transition to an integrated and validated
1949 Yocto Project kernel.
1950 </para>
1951
1873<!--<para> 1952<!--<para>
1874The next few sections describe the process: 1953The next few sections describe the process:
1875</para> --> 1954</para> -->