diff options
-rw-r--r-- | README | 149 |
1 files changed, 81 insertions, 68 deletions
@@ -21,15 +21,11 @@ Dependencies | |||
21 | This layer depends on: | 21 | This layer depends on: |
22 | 22 | ||
23 | URI: git://git.openembedded.org/bitbake | 23 | URI: git://git.openembedded.org/bitbake |
24 | branch: master | 24 | branch: 1.34 |
25 | 25 | ||
26 | URI: git://git.openembedded.org/openembedded-core | 26 | URI: git://git.openembedded.org/openembedded-core |
27 | layers: meta | 27 | layers: meta |
28 | branch: master | 28 | branch: pyro |
29 | |||
30 | URI: git://git.yoctoproject.org/meta-intel | ||
31 | layers: intel | ||
32 | branch: master | ||
33 | 29 | ||
34 | 30 | ||
35 | Table of Contents | 31 | Table of Contents |
@@ -41,6 +37,7 @@ Table of Contents | |||
41 | b. Booting the intel-common BSP images | 37 | b. Booting the intel-common BSP images |
42 | c. Booting the intel-quark BSP image on a Galileo board | 38 | c. Booting the intel-quark BSP image on a Galileo board |
43 | III. Technical Miscellany | 39 | III. Technical Miscellany |
40 | Benefits of using meta-intel | ||
44 | The intel-common kernel package architecture | 41 | The intel-common kernel package architecture |
45 | Intel-specific machine features | 42 | Intel-specific machine features |
46 | IV. Tested Hardware | 43 | IV. Tested Hardware |
@@ -149,7 +146,7 @@ You should then be able to build an image as such: | |||
149 | $ source oe-init-build-env | 146 | $ source oe-init-build-env |
150 | $ bitbake core-image-sato | 147 | $ bitbake core-image-sato |
151 | 148 | ||
152 | At the end of a successful build, you should have a live image that | 149 | At the end of a successful build, you should have an image that |
153 | you can boot from a USB flash drive (see instructions on how to do | 150 | you can boot from a USB flash drive (see instructions on how to do |
154 | that below, in the section 'Booting the intel-common BSP images'). | 151 | that below, in the section 'Booting the intel-common BSP images'). |
155 | 152 | ||
@@ -176,12 +173,11 @@ The BSP /binary directory or build contains bootable live images, | |||
176 | which can be used to directly boot Yocto off of a USB flash drive. | 173 | which can be used to directly boot Yocto off of a USB flash drive. |
177 | 174 | ||
178 | Under Linux, insert a USB flash drive. Assuming the USB flash drive | 175 | Under Linux, insert a USB flash drive. Assuming the USB flash drive |
179 | takes device /dev/sdf, use dd to copy the live image to it. For | 176 | takes device /dev/sdf, use dd to copy the image to it. For example: |
180 | example: | ||
181 | 177 | ||
182 | # dd if=core-image-sato-intel-corei7-64.hddimg of=/dev/sdf | 178 | $ dd if=core-image-sato-intel-corei7-64.wic of=/dev/sdf |
183 | # sync | 179 | $ sync |
184 | # eject /dev/sdf | 180 | $ eject /dev/sdf |
185 | 181 | ||
186 | This should give you a bootable USB flash device. Insert the device | 182 | This should give you a bootable USB flash device. Insert the device |
187 | into a bootable USB socket on the target, and power on. This should | 183 | into a bootable USB socket on the target, and power on. This should |
@@ -200,7 +196,7 @@ If you find you're getting corrupt images on the USB (it doesn't show | |||
200 | the syslinux boot: prompt, or the boot: prompt contains strange | 196 | the syslinux boot: prompt, or the boot: prompt contains strange |
201 | characters), try doing this first: | 197 | characters), try doing this first: |
202 | 198 | ||
203 | # dd if=/dev/zero of=/dev/sdf bs=1M count=512 | 199 | $ dd if=/dev/zero of=/dev/sdf bs=1M count=512 |
204 | 200 | ||
205 | c. Booting the intel-quark BSP image on a Galileo board | 201 | c. Booting the intel-quark BSP image on a Galileo board |
206 | ------------------------------------------------------- | 202 | ------------------------------------------------------- |
@@ -212,49 +208,31 @@ find the bootable image in the build/tmp/deploy/images/xxx directory, | |||
212 | where again 'xxx' refers to the machine name used in the build. | 208 | where again 'xxx' refers to the machine name used in the build. |
213 | 209 | ||
214 | The Galileo board can boot off of either an SD card or USB storage | 210 | The Galileo board can boot off of either an SD card or USB storage |
215 | media that has a special disk layout. The 'wic' tool can be used to | 211 | media that has a special disk layout. The 'wic' tool can be used to |
216 | create directly bootable images for either of the two formats via the | 212 | create directly bootable images for either of the two formats via the |
217 | following steps. | 213 | following steps. As of meta-intel 6.0-morty-2.2 or newer, wic images are |
218 | 214 | created automatically during build time, and the manual use of wic is | |
219 | If you haven't already, you need to build parted-native. (You will get | 215 | not necessary. By default, the galileodisk-sd wic kickstart file is used, |
220 | an error message when running the wic script if you haven't.) | 216 | which targets SD cards. This can be changed by setting the WKS_FILE to |
221 | 217 | something else in local.conf, such as the following: | |
222 | $ bitbake parted-native | ||
223 | |||
224 | Use the wic script to create an SD card image: | ||
225 | |||
226 | $ wic list images | ||
227 | galileodisk-sd Create an Galileo Gen 1/2 disk image (SD card) | ||
228 | galileodisk-usb Create an Galileo Gen 1/2 disk image (USB Storage) | ||
229 | mkgummidisk Create an EFI disk image | ||
230 | 218 | ||
231 | Assuming you want to boot the 'core-image-minimal' image for SD card media: | 219 | WKS_FILE = “galileodisk-usb” |
232 | 220 | ||
233 | $ wic create galileodisk-sd -e core-image-minimal | 221 | If your build is successful, a .wic image will be created in the usual |
222 | deploy directory. Write this image to an SD card: | ||
234 | 223 | ||
235 | If successful, the wic script generates the image and prints its location: | 224 | $ sudo dd if=/path/to/image/image-name.wic of=/dev/your_sd_dev |
225 | $ sync | ||
226 | $ sudo eject /dev/your_sd_dev | ||
236 | 227 | ||
237 | Info: The new image(s) can be found here: | 228 | Insert the SD card into the Galileo and power on. |
238 | /var/tmp/wic/build/galileodisk-sd-201604211444-mmcblk0.direct | ||
239 | ... | ||
240 | 229 | ||
241 | Write the output image to an SD Card | 230 | The Galileo board can boot from an hddimg formatted USB drive as well, |
242 | 231 | but currently only live-boot, and not installation, is supported. | |
243 | $ sudo dd if=/path/to/image/galileodisk-sd-*-mmcblk0.direct of=/dev/your_sd_dev | 232 | An image in hddimg format is generated when you build the quark BSP. |
244 | 233 | You can follow the procedure in II.b to use dd command to prepare your USB | |
245 | Insert the SD Card into the reference platform and power on. | 234 | drive, then press F7 key during startup to bring up the boot option menu. |
246 | 235 | Choose the UEFI USB boot option for the drive to boot the system. If the board | |
247 | To create a direct-boot image for USB storage media, simply specify | ||
248 | galileodisk-usb instead of galileodisk-sd in the "wic create ..." | ||
249 | command, then write the output image to USB storage media and boot it. | ||
250 | |||
251 | Actually, Galileo board can boot off with an image in hddimg format | ||
252 | from USB drives too. But only live-boot, no installation, is supported | ||
253 | at this point. An image in hddimg format is generated when you build | ||
254 | quark BSP. You can follow the procedure in II.b to use dd command to | ||
255 | prepare your USB drive, then press F7 key as what board prompts when it | ||
256 | boots. Galileo should show a boot option menu for you to choose the | ||
257 | UEFI USB boot option for the drive to boot the system. If the board | ||
258 | already passes this stage and show a grub boot menu, you can press 'c' | 236 | already passes this stage and show a grub boot menu, you can press 'c' |
259 | key and then type "quit" in grub shell. The board should come back to | 237 | key and then type "quit" in grub shell. The board should come back to |
260 | the UEFI boot menu. | 238 | the UEFI boot menu. |
@@ -262,6 +240,46 @@ the UEFI boot menu. | |||
262 | III. Technical Miscellany | 240 | III. Technical Miscellany |
263 | ========================= | 241 | ========================= |
264 | 242 | ||
243 | Benefits of using meta-intel | ||
244 | ---------------------------- | ||
245 | |||
246 | Using meta-intel has the following benefits over a generic BSP: | ||
247 | |||
248 | tune flags | ||
249 | ++++++++++ | ||
250 | intel-* MACHINEs each have different compilation flags appropriate for their | ||
251 | targeted hardware sets. intel-corei7-64 has tune flags appropriate for modern | ||
252 | 64-bit Intel Core i microarchitecture, and includes instruction sets up to | ||
253 | SSE4.2. intel-core2-32 has tune flags appropriate for legacy 32-bit Intel Core2 | ||
254 | microarchitecture, and includes instruction sets up to SSE3. intel-quark | ||
255 | contains a subset of the intel-core2-32 instruction set, as quark does not | ||
256 | support prefix locking instructions. | ||
257 | |||
258 | linux-intel kernel | ||
259 | ++++++++++++++++++ | ||
260 | The linux-intel kernel is an initiative to bring better Intel(R) hardware | ||
261 | support to the current LTS linux kernel. It contains a base LTS kernel with | ||
262 | additional backports from upstream Intel drivers. In addition, a default kernel | ||
263 | config containing most features found on Intel boards is supplied via the | ||
264 | yocto-kernel-cache. | ||
265 | |||
266 | graphics stack | ||
267 | ++++++++++++++ | ||
268 | Meta-intel provides the latest Intel Graphics Linux Stack drivers to support | ||
269 | Intel hardware as defined by the https://01.org/linuxgraphics. | ||
270 | |||
271 | Other software | ||
272 | ++++++++++++++ | ||
273 | * intel ucode - provides the latest microcode updates for Intel processors | ||
274 | |||
275 | * thermald - which proactively controls thermal, using P-states, T-states, and | ||
276 | the Intel power clamp driver. | ||
277 | (https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon) | ||
278 | |||
279 | * RMC - Runtime Machine Configuration, which allows the bootload to determine | ||
280 | board and CPU information in order to set specific kernel command line | ||
281 | information at startup. | ||
282 | |||
265 | The intel-common kernel package architecture | 283 | The intel-common kernel package architecture |
266 | -------------------------------------------- | 284 | -------------------------------------------- |
267 | 285 | ||
@@ -295,9 +313,9 @@ that BSP. | |||
295 | To make these features available for your machine, you will need to: | 313 | To make these features available for your machine, you will need to: |
296 | 314 | ||
297 | 1. include a configuration line such as the below in bblayers.conf | 315 | 1. include a configuration line such as the below in bblayers.conf |
298 | BBLAYERS += "<local path>/meta-intel" | 316 | BBLAYERS += "<local path>/meta-intel" |
299 | 2. include the following line in the machine configuration file | 317 | 2. include the following line in the machine configuration file |
300 | require conf/machine/include/meta-intel.inc | 318 | require conf/machine/include/meta-intel.inc |
301 | 319 | ||
302 | Once the above requirements are met, the machine features provided by | 320 | Once the above requirements are met, the machine features provided by |
303 | the meta-intel layer will be available for the BSP to use. | 321 | the meta-intel layer will be available for the BSP to use. |
@@ -314,7 +332,7 @@ These machine features can be included by listing them in the | |||
314 | MACHINE_FEATURES variable in the machine configuration file. For | 332 | MACHINE_FEATURES variable in the machine configuration file. For |
315 | example: | 333 | example: |
316 | 334 | ||
317 | MACHINE_FEATURES += "intel-ucode" | 335 | MACHINE_FEATURES += "intel-ucode" |
318 | 336 | ||
319 | Machine feature details | 337 | Machine feature details |
320 | +++++++++++++++++++++++ | 338 | +++++++++++++++++++++++ |
@@ -369,7 +387,7 @@ Machine feature details | |||
369 | the fri2 BSP, the cpuid can be determined as such: | 387 | the fri2 BSP, the cpuid can be determined as such: |
370 | 388 | ||
371 | [root@fri2 ~]# iucode_tool -S | 389 | [root@fri2 ~]# iucode_tool -S |
372 | iucode_tool: system has processor(s) with signature 0x00020661 | 390 | iucode_tool: system has processor(s) with signature 0x00020661 |
373 | 391 | ||
374 | Given that output, a suitable UCODE_FILTER_PARAMETERS variable | 392 | Given that output, a suitable UCODE_FILTER_PARAMETERS variable |
375 | definition could be specified in the machine configuration as | 393 | definition could be specified in the machine configuration as |
@@ -390,25 +408,20 @@ Machine feature details | |||
390 | IV. Tested Hardware | 408 | IV. Tested Hardware |
391 | =================== | 409 | =================== |
392 | 410 | ||
393 | Of the BSPs currently included in meta-intel, the following have | 411 | The following undergo regular basic testing with their respective MACHINE types. |
394 | passed initial testing with the intel-common BSPs: | 412 | Note that both 64-bit and 32-bit firmware is available for the MinnowBoard |
413 | Turbot, so it is tested against both intel-corei7-64 and intel-core2-32. | ||
395 | 414 | ||
396 | intel-corei7-64: | 415 | intel-corei7-64: |
397 | 416 | NUC6i5SYH | |
398 | crystalforest-server | 417 | MinnowBoard Turbot |
399 | crystalforest-gladden | 418 | Braswell RVP |
400 | haswell-wc | ||
401 | nuc (Ivy Bridge and Haswell, manual audio config required) | ||
402 | sugarbay | ||
403 | 419 | ||
404 | intel-core2-32: | 420 | intel-core2-32: |
421 | MinnowBoard Turbot | ||
405 | 422 | ||
406 | <currently under test> | 423 | Intel-quark: |
407 | 424 | Galileo 2 | |
408 | If you are interested in a BSP not listed here, chances are we are | ||
409 | currently working on resolving some configuration issues with it. | ||
410 | Please check the bugzilla and check in with us on the meta-intel | ||
411 | mailing list. | ||
412 | 425 | ||
413 | 426 | ||
414 | V. Guidelines for submitting patches | 427 | V. Guidelines for submitting patches |