diff options
Diffstat (limited to 'documentation/kernel-dev/kernel-dev-common.xml')
-rw-r--r-- | documentation/kernel-dev/kernel-dev-common.xml | 149 |
1 files changed, 147 insertions, 2 deletions
diff --git a/documentation/kernel-dev/kernel-dev-common.xml b/documentation/kernel-dev/kernel-dev-common.xml index a9aafd3c21..d49aa3ce17 100644 --- a/documentation/kernel-dev/kernel-dev-common.xml +++ b/documentation/kernel-dev/kernel-dev-common.xml | |||
@@ -84,11 +84,11 @@ | |||
84 | You also name it accordingly based on the linux-yocto recipe | 84 | You also name it accordingly based on the linux-yocto recipe |
85 | you are using. | 85 | you are using. |
86 | For example, if you are modifying the | 86 | For example, if you are modifying the |
87 | <filename>meta/recipes-kernel/linux/linux-yocto_3.19.bb</filename> | 87 | <filename>meta/recipes-kernel/linux/linux-yocto_4.4.bb</filename> |
88 | recipe, the append file will typically be located as follows | 88 | recipe, the append file will typically be located as follows |
89 | within your custom layer: | 89 | within your custom layer: |
90 | <literallayout class='monospaced'> | 90 | <literallayout class='monospaced'> |
91 | <replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto_3.19.bbappend | 91 | <replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto_4.4.bbappend |
92 | </literallayout> | 92 | </literallayout> |
93 | The append file should initially extend the | 93 | The append file should initially extend the |
94 | <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink> | 94 | <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink> |
@@ -114,6 +114,151 @@ | |||
114 | <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>. | 114 | <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>. |
115 | </note> | 115 | </note> |
116 | </para> | 116 | </para> |
117 | |||
118 | <para> | ||
119 | As an example, consider the following append file | ||
120 | used by the BSPs in <filename>meta-yocto-bsp</filename>: | ||
121 | <literallayout class='monospaced'> | ||
122 | meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend | ||
123 | </literallayout> | ||
124 | The following listing shows the file. | ||
125 | Be aware that the actual commit ID strings in this | ||
126 | example listing might be different than the actual strings | ||
127 | in the file from the <filename>meta-yocto-bsp</filename> | ||
128 | layer upstream. | ||
129 | <literallayout class='monospaced'> | ||
130 | KBRANCH_genericx86 = "standard/base" | ||
131 | KBRANCH_genericx86-64 = "standard/base" | ||
132 | |||
133 | KMACHINE_genericx86 ?= "common-pc" | ||
134 | KMACHINE_genericx86-64 ?= "common-pc-64" | ||
135 | KBRANCH_edgerouter = "standard/edgerouter" | ||
136 | KBRANCH_beaglebone = "standard/beaglebone" | ||
137 | KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb" | ||
138 | |||
139 | SRCREV_machine_genericx86 ?= "ad8b1d659ddd2699ebf7d50ef9de8940b157bfc2" | ||
140 | SRCREV_machine_genericx86-64 ?= "ad8b1d659ddd2699ebf7d50ef9de8940b157bfc2" | ||
141 | SRCREV_machine_edgerouter ?= "cebe1ad56aebd89e0de29412e19433fb441bf13c" | ||
142 | SRCREV_machine_beaglebone ?= "cebe1ad56aebd89e0de29412e19433fb441bf13c" | ||
143 | SRCREV_machine_mpc8315e-rdb ?= "06c0dbdcba374ca7f92a53d69292d6bb7bc9b0f3" | ||
144 | |||
145 | COMPATIBLE_MACHINE_genericx86 = "genericx86" | ||
146 | COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64" | ||
147 | COMPATIBLE_MACHINE_edgerouter = "edgerouter" | ||
148 | COMPATIBLE_MACHINE_beaglebone = "beaglebone" | ||
149 | COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb" | ||
150 | |||
151 | LINUX_VERSION_genericx86 = "4.4.41" | ||
152 | LINUX_VERSION_genericx86-64 = "4.4.41" | ||
153 | LINUX_VERSION_edgerouter = "4.4.53" | ||
154 | LINUX_VERSION_beaglebone = "4.4.53" | ||
155 | LINUX_VERSION_mpc8315e-rdb = "4.4.53" | ||
156 | </literallayout> | ||
157 | This append file contains statements used to support | ||
158 | several BSPs that ship with the Yocto Project. | ||
159 | The file defines machines using the | ||
160 | <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink> | ||
161 | variable and uses the | ||
162 | <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink> | ||
163 | variable to ensure the machine name used by the OpenEmbedded | ||
164 | build system maps to the machine name used by the Linux Yocto | ||
165 | kernel. | ||
166 | The file also uses the optional | ||
167 | <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink> | ||
168 | variable to ensure the build process uses the | ||
169 | appropriate kernel branch. | ||
170 | </para> | ||
171 | |||
172 | <para> | ||
173 | Although this particular example does not use it, the | ||
174 | <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink> | ||
175 | variable could be used to enable features specific to | ||
176 | the kernel. | ||
177 | The append file points to specific commits in the | ||
178 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> | ||
179 | Git repository and the <filename>meta</filename> Git repository | ||
180 | branches to identify the exact kernel needed to build the | ||
181 | BSP. | ||
182 | </para> | ||
183 | |||
184 | <para> | ||
185 | One thing missing in this particular BSP, which you will | ||
186 | typically need when developing a BSP, is the kernel configuration | ||
187 | file (<filename>.config</filename>) for your BSP. | ||
188 | When developing a BSP, you probably have a kernel configuration | ||
189 | file or a set of kernel configuration files that, when taken | ||
190 | together, define the kernel configuration for your BSP. | ||
191 | You can accomplish this definition by putting the configurations | ||
192 | in a file or a set of files inside a directory located at the | ||
193 | same level as your kernel's append file and having the same | ||
194 | name as the kernel's main recipe file. | ||
195 | With all these conditions met, simply reference those files in the | ||
196 | <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> | ||
197 | statement in the append file. | ||
198 | </para> | ||
199 | |||
200 | <para> | ||
201 | For example, suppose you had some configuration options | ||
202 | in a file called <filename>network_configs.cfg</filename>. | ||
203 | You can place that file inside a directory named | ||
204 | <filename>linux-yocto</filename> and then add | ||
205 | a <filename>SRC_URI</filename> statement such as the | ||
206 | following to the append file. | ||
207 | When the OpenEmbedded build system builds the kernel, the | ||
208 | configuration options are picked up and applied. | ||
209 | <literallayout class='monospaced'> | ||
210 | SRC_URI += "file://network_configs.cfg" | ||
211 | </literallayout> | ||
212 | </para> | ||
213 | |||
214 | <para> | ||
215 | To group related configurations into multiple files, you | ||
216 | perform a similar procedure. | ||
217 | Here is an example that groups separate configurations | ||
218 | specifically for Ethernet and graphics into their own | ||
219 | files and adds the configurations by using a | ||
220 | <filename>SRC_URI</filename> statement like the following | ||
221 | in your append file: | ||
222 | <literallayout class='monospaced'> | ||
223 | SRC_URI += "file://myconfig.cfg \ | ||
224 | file://eth.cfg \ | ||
225 | file://gfx.cfg" | ||
226 | </literallayout> | ||
227 | </para> | ||
228 | |||
229 | <para> | ||
230 | Another variable you can use in your kernel recipe append | ||
231 | file is the | ||
232 | <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink> | ||
233 | variable. | ||
234 | When you use this statement, you are extending the locations | ||
235 | used by the OpenEmbedded system to look for files and | ||
236 | patches as the recipe is processed. | ||
237 | </para> | ||
238 | |||
239 | <note> | ||
240 | <para> | ||
241 | Other methods exist to accomplish grouping and defining configuration options. | ||
242 | For example, if you are working with a local clone of the kernel repository, | ||
243 | you could checkout the kernel's <filename>meta</filename> branch, make your changes, | ||
244 | and then push the changes to the local bare clone of the kernel. | ||
245 | The result is that you directly add configuration options to the | ||
246 | <filename>meta</filename> branch for your BSP. | ||
247 | The configuration options will likely end up in that location anyway if the BSP gets | ||
248 | added to the Yocto Project. | ||
249 | </para> | ||
250 | |||
251 | <para> | ||
252 | In general, however, the Yocto Project maintainers take care of moving the | ||
253 | <filename>SRC_URI</filename>-specified | ||
254 | configuration options to the kernel's <filename>meta</filename> branch. | ||
255 | Not only is it easier for BSP developers to not have to worry about putting those | ||
256 | configurations in the branch, but having the maintainers do it allows them to apply | ||
257 | 'global' knowledge about the kinds of common configuration options multiple BSPs in | ||
258 | the tree are typically using. | ||
259 | This allows for promotion of common configurations into common features. | ||
260 | </para> | ||
261 | </note> | ||
117 | </section> | 262 | </section> |
118 | 263 | ||
119 | <section id='applying-patches'> | 264 | <section id='applying-patches'> |