diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml
index 1ae17b895d..d18f0aecd6 100644
--- a/documentation/yocto-project-qs/yocto-project-qs.xml
+++ b/documentation/yocto-project-qs/yocto-project-qs.xml
@@ -390,8 +390,8 @@
- You can try out the Yocto Project using the command-line interface
- by finishing this quick start, which presents steps that let you
+ To use the Yocto Project through the command-line interface,
+ finish this quick start, which presents steps that let you
do the following:
@@ -400,230 +400,239 @@
Easily change configurations so that you can quickly
- create a second image, which would be for MinnowBoard
+ create a second image that you can load onto bootable
+ media and actually boot target hardware.
+ This example uses the MinnowBoard
MAX-compatible boards.
- The steps in this section do not provide detail, but rather
- provide minimal, working commands and examples designed to
- just get you started.
+ The steps in the following two sections do not provide detail,
+ but rather provide minimal, working commands and examples
+ designed to just get you started.
For more details, see the appropriate manuals in the
Yocto Project manual set.
-
- Use the following commands to build your image.
- The OpenEmbedded build system creates an entire Linux
- distribution, including the toolchain, from source.
- Note about Network Proxies
-
- By default, the build process searches for source code
- using a pre-determined order through a set of
- locations.
- If you are working behind a firewall and your build
- host is not set up for proxies, you could encounter
- problems with the build process when fetching source
- code (e.g. fetcher failures or Git failures).
-
+
+ Building an Image for Emulation
-
- If you do not know your proxy settings, consult your
- local network infrastructure resources and get that
- information.
- A good starting point could also be to check your web
- browser settings.
- Finally, you can find more information on using the
- Yocto Project behind a firewall in the Yocto Project
- Reference Manual
- FAQ
- and on the
- "Working Behind a Network Proxy"
- wiki page.
-
-
-
+
+ Use the following commands to build your image.
+ The OpenEmbedded build system creates an entire Linux
+ distribution, including the toolchain, from source.
+ Note about Network Proxies
+
+ By default, the build process searches for source code
+ using a pre-determined order through a set of
+ locations.
+ If you are working behind a firewall and your build
+ host is not set up for proxies, you could encounter
+ problems with the build process when fetching source
+ code (e.g. fetcher failures or Git failures).
+
-
-
- Be Sure Your Build Host is Set Up:
- The steps to build an image in this section depend on
- your build host being properly set up.
- Be sure you have worked through the requirements
- described in the
- "Setting Up to Use the Yocto Project"
- section.
-
- Check Out Your Branch:
- Be sure you are in the
- Source Directory
- (e.g. poky) and then check out
- the branch associated with the latest Yocto Project
- Release:
-
+
+ If you do not know your proxy settings, consult your
+ local network infrastructure resources and get that
+ information.
+ A good starting point could also be to check your web
+ browser settings.
+ Finally, you can find more information on using the
+ Yocto Project behind a firewall in the Yocto Project
+ Reference Manual
+ FAQ
+ and on the
+ "Working Behind a Network Proxy"
+ wiki page.
+
+
+
+
+
+
+ Be Sure Your Build Host is Set Up:
+ The steps to build an image in this section depend on
+ your build host being properly set up.
+ Be sure you have worked through the requirements
+ described in the
+ "Setting Up to Use the Yocto Project"
+ section.
+
+ Check Out Your Branch:
+ Be sure you are in the
+ Source Directory
+ (e.g. poky) and then check out
+ the branch associated with the latest Yocto Project
+ Release:
+
$ cd ~/poky
$ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP;
-
- Git's checkout command checks out
- the current Yocto Project release into a local branch
- whose name matches the release (i.e.
- &DISTRO_NAME_NO_CAP;).
- The local branch tracks the upstream branch of the
- same name.
- Creating your own branch based on the released
- branch ensures you are using the latest files for
- that release.
-
- Initialize the Build Environment:
- Run the
- &OE_INIT_FILE;
- environment setup script to define the OpenEmbedded
- build environment on your build host.
-
+
+ Git's checkout command checks out
+ the current Yocto Project release into a local branch
+ whose name matches the release (i.e.
+ &DISTRO_NAME_NO_CAP;).
+ The local branch tracks the upstream branch of the
+ same name.
+ Creating your own branch based on the released
+ branch ensures you are using the latest files for
+ that release.
+
+ Initialize the Build Environment:
+ Run the
+ &OE_INIT_FILE;
+ environment setup script to define the OpenEmbedded
+ build environment on your build host.
+
$ source &OE_INIT_FILE;
-
- Among other things, the script creates the
- Build Directory,
- which is build in this case
- and is located in the
- Source Directory.
- After the script runs, your current working directory
- is set to the Build Directory.
- Later, when the build completes, the Build Directory
- contains all the files created during the build.
-
- For information on running a memory-resident
- BitBake,
- see the
- oe-init-build-env-memres
- setup script.
-
-
- Examine Your Local Configuration File:
- When you set up the build environment, a local
- configuration file named
- local.conf becomes available in
- a conf subdirectory of the
- Build Directory.
- Before using BitBake to start the build, you can
- look at this file and be sure your general
- configurations are how you want them:
-
-
- To help conserve disk space during builds,
- you can add the following statement to your
- project's configuration file, which for this
- example is
- poky/build/conf/local.conf.
- Adding this statement deletes the work
- directory used for building a recipe once the
- recipe is built.
-
+
+ Among other things, the script creates the
+ Build Directory,
+ which is build in this case
+ and is located in the
+ Source Directory.
+ After the script runs, your current working directory
+ is set to the Build Directory.
+ Later, when the build completes, the Build Directory
+ contains all the files created during the build.
+
+ For information on running a memory-resident
+ BitBake,
+ see the
+ oe-init-build-env-memres
+ setup script.
+
+
+ Examine Your Local Configuration File:
+ When you set up the build environment, a local
+ configuration file named
+ local.conf becomes available in
+ a conf subdirectory of the
+ Build Directory.
+ Before using BitBake to start the build, you can
+ look at this file and be sure your general
+ configurations are how you want them:
+
+
+ To help conserve disk space during builds,
+ you can add the following statement to your
+ project's configuration file, which for this
+ example is
+ poky/build/conf/local.conf.
+ Adding this statement deletes the work
+ directory used for building a recipe once the
+ recipe is built.
+
INHERIT += "rm_work"
-
-
-
- By default, the target machine for the build is
- qemux86,
- which produces an image that can be used in
- the QEMU emulator and is targeted at an
- Intel
- 32-bit based architecture.
- Further on in this example, this default is
- easily changed through the
- MACHINE
- variable so that you can quickly
- build an image for a different machine.
-
-
- Another consideration before you build is the
- package manager used when creating the image.
- The default local.conf
- file selects the RPM package manager.
- You can control this configuration by using the
- PACKAGE_CLASSES
- variable.
- Selection of the package manager is separate
- from whether package management is used at runtime
- in the target image.
- For additional package manager selection
- information, see the
- "package.bbclass"
- section in the Yocto Project Reference Manual.
-
-
-
- Start the Build:
- Continue with the following command to build an OS image
- for the target, which is
- core-image-sato in this example:
-
- Depending on the number of processors and cores, the
- amount of RAM, the speed of your Internet connection
- and other factors, the build process could take several
- hours the first time you run it.
- Subsequent builds run much faster since parts of the
- build are cached.
-
-
+
+
+
+ By default, the target machine for the build is
+ qemux86,
+ which produces an image that can be used in
+ the QEMU emulator and is targeted at an
+ Intel
+ 32-bit based architecture.
+ Further on in this example, this default is
+ easily changed through the
+ MACHINE
+ variable so that you can quickly
+ build an image for a different machine.
+
+
+ Another consideration before you build is the
+ package manager used when creating the image.
+ The default local.conf
+ file selects the RPM package manager.
+ You can control this configuration by using the
+ PACKAGE_CLASSES
+ variable.
+ Selection of the package manager is separate
+ from whether package management is used at runtime
+ in the target image.
+ For additional package manager selection
+ information, see the
+ "package.bbclass"
+ section in the Yocto Project Reference Manual.
+
+
+
+ Start the Build:
+ Continue with the following command to build an OS image
+ for the target, which is
+ core-image-sato in this example:
+
+ Depending on the number of processors and cores, the
+ amount of RAM, the speed of your Internet connection
+ and other factors, the build process could take several
+ hours the first time you run it.
+ Subsequent builds run much faster since parts of the
+ build are cached.
+
+
$ bitbake core-image-sato
-
- For information on using the
- bitbake command, see the
- "BitBake"
- section in the Yocto Project Reference Manual, or see the
- "BitBake Command"
- section in the BitBake User Manual.
- For information on other targets, see the
- "Images"
- chapter in the Yocto Project Reference Manual.
-
- Simulate Your Image Using QEMU:
- Once this particular image is built, you can start QEMU
- and run the image:
-
+
+ For information on using the
+ bitbake command, see the
+ "BitBake"
+ section in the Yocto Project Reference Manual, or see the
+ "BitBake Command"
+ section in the BitBake User Manual.
+ For information on other targets, see the
+ "Images"
+ chapter in the Yocto Project Reference Manual.
+
+ Simulate Your Image Using QEMU:
+ Once this particular image is built, you can start QEMU
+ and run the image:
+
$ runqemu qemux86
-
- If you want to learn more about running QEMU, see the
- "Using the Quick EMUlator (QEMU)"
- chapter in the Yocto Project Development Manual.
-
- Exit QEMU:
- Exit QEMU by either clicking on the shutdown icon or by
- opening a terminal, typing
- poweroff, and then pressing "Enter".
-
-
-
+
+ If you want to learn more about running QEMU, see the
+ "Using the Quick EMUlator (QEMU)"
+ chapter in the Yocto Project Development Manual.
+
+ Exit QEMU:
+ Exit QEMU by either clicking on the shutdown icon or by
+ opening a terminal, typing
+ poweroff, and then pressing "Enter".
+
+
+
+
-
- The following steps show how easy it is to set up to build an
- image for a new machine.
- These steps build an image for the MinnowBoard MAX, which is
- supported by the Yocto Project and the
- meta-intelintel-corei7-64
- and intel-core2-32 Board Support Packages
- (BSPs).
-
- The MinnowBoard MAX ships with 64-bit firmware.
- If you want to use the board in 32-bit mode, you must
- download the
- 32-bit firmware.
-
-
+
+ Building an Image for Hardware
-
-
- Create a Local Copy of the
- meta-intel Repository:
- Building an image for the MinnowBoard MAX requires the
- meta-intel layer.
- Use the git clone command to create
- a local copy of the repository inside your
- Source Directory,
- which is poky in this example:
-
+
+ The following steps show how easy it is to set up to build an
+ image for a new machine.
+ These steps build an image for the MinnowBoard MAX, which is
+ supported by the Yocto Project and the
+ meta-intelintel-corei7-64
+ and intel-core2-32 Board Support Packages
+ (BSPs).
+
+ The MinnowBoard MAX ships with 64-bit firmware.
+ If you want to use the board in 32-bit mode, you must
+ download the
+ 32-bit firmware.
+
+
+
+
+
+ Create a Local Copy of the
+ meta-intel Repository:
+ Building an image for the MinnowBoard MAX requires the
+ meta-intel layer.
+ Use the git clone command to create
+ a local copy of the repository inside your
+ Source Directory,
+ which is poky in this example:
+
$ cd $HOME/poky
$ git clone git://git.yoctoproject.org/meta-intel
Cloning into 'meta-intel'...
@@ -633,132 +642,133 @@
remote: Total 11988 (delta 6881), reused 11752 (delta 6645)
Resolving deltas: 100% (6881/6881), done.
Checking connectivity... done.
-
- By default when you clone a Git repository, the
- "master" branch is checked out.
- Before you build your image that uses the
- meta-intel layer, you must be
- sure that both repositories
- (meta-intel and
- poky) are using the same releases.
- Consequently, you need to checkout out the
- "&DISTRO_NAME_NO_CAP;" release after
- cloning meta-intel:
-
+
+ By default when you clone a Git repository, the
+ "master" branch is checked out.
+ Before you build your image that uses the
+ meta-intel layer, you must be
+ sure that both repositories
+ (meta-intel and
+ poky) are using the same releases.
+ Consequently, you need to checkout out the
+ "&DISTRO_NAME_NO_CAP;" release after
+ cloning meta-intel:
+
$ cd $HOME/poky/meta-intel
$ git checkout &DISTRO_NAME_NO_CAP;
Branch &DISTRO_NAME_NO_CAP; set up to track remote branch &DISTRO_NAME_NO_CAP; from origin.
Switched to a new branch '&DISTRO_NAME_NO_CAP;'
-
-
- Configure the Build:
- To configure the build, you edit the
- bblayers.conf and
- local.conf files, both of which are
- located in the build/conf directory.
-
+
+
+ Configure the Build:
+ To configure the build, you edit the
+ bblayers.conf and
+ local.conf files, both of which are
+ located in the build/conf directory.
+
- Here is a quick way to make the edits.
- The first command uses the
- bitbake-layers add-layer command
- to add the meta-intel
- layer, which contains the intel-core*
- BSPs to the build.
- The second command selects the BSP by setting the
- MACHINE
- variable.
-
+ Here is a quick way to make the edits.
+ The first command uses the
+ bitbake-layers add-layer command
+ to add the meta-intel
+ layer, which contains the intel-core*
+ BSPs to the build.
+ The second command selects the BSP by setting the
+ MACHINE
+ variable.
+
$ cd $HOME/poky/build
$ bitbake-layers add-layer "$HOME/poky/meta-intel"
$ echo 'MACHINE = "intel-corei7-64"' >> conf/local.conf
-
- Notes
-
- If you want a 64-bit build, use the following:
-
+
+ Notes
+
+ If you want a 64-bit build, use the following:
+
$ echo 'MACHINE = "intel-corei7-64"' >> conf/local.conf
-
-
+
+
-
- If you want 32-bit images, use the following:
-
+
+ If you want 32-bit images, use the following:
+
$ echo 'MACHINE = "intel-core2-32"' >> conf/local.conf
-
-
-
-
- Build an Image for MinnowBoard MAX:
- The type of image you build depends on your goals.
- For example, the previous build created a
- core-image-sato image, which is an
- image with Sato support.
- It is possible to build many image types for the
- MinnowBoard MAX.
- Some possibilities are core-image-base,
- which is a console-only image.
- Another choice could be a
- core-image-full-cmdline, which is
- another console-only image but has more full-features
- Linux system functionality installed.
- For types of images you can build using the Yocto
- Project, see the
- "Images"
- chapter in the Yocto Project Reference Manual.
- Because configuration changes are minimal to set up
- for this second build, the OpenEmbedded build system can
- re-use files from previous builds as much as possible.
- Re-using files means this second build will be much faster
- than an initial build.
- For this example, the core-image-base
- image is built:
-
+
+
+
+
+ Build an Image for MinnowBoard MAX:
+ The type of image you build depends on your goals.
+ For example, the previous build created a
+ core-image-sato image, which is an
+ image with Sato support.
+ It is possible to build many image types for the
+ MinnowBoard MAX.
+ Some possibilities are core-image-base,
+ which is a console-only image.
+ Another choice could be a
+ core-image-full-cmdline, which is
+ another console-only image but has more full-features
+ Linux system functionality installed.
+ For types of images you can build using the Yocto
+ Project, see the
+ "Images"
+ chapter in the Yocto Project Reference Manual.
+ Because configuration changes are minimal to set up
+ for this second build, the OpenEmbedded build system can
+ re-use files from previous builds as much as possible.
+ Re-using files means this second build will be much faster
+ than an initial build.
+ For this example, the core-image-base
+ image is built:
+
$ bitbake core-image-base
-
- Once the build completes, the resulting console-only image
- is located in the Build Directory here:
-
+
+ Once the build completes, the resulting console-only image
+ is located in the Build Directory here:
+
tmp/deploy/images/intel-corei7-64/core-image-base-intel-corei7-64.hddimg
-
-
- Write the Image:
- You can write the image just built to a bootable media
- (e.g. a USB key, SATA drive, SD card, etc.) using the
- dd utility:
-
+
+
+ Write the Image:
+ You can write the image just built to a bootable media
+ (e.g. a USB key, SATA drive, SD card, etc.) using the
+ dd utility:
+
$ sudo dd if=tmp/deploy/images/intel-corei7-64/core-image-minimal-intel-corei7-64.wic of=TARGET_DEVICE
-
- In the previous command, the
- TARGET_DEVICE is the device node in
- the host machine (e.g. /dev/sdc, which
- is most likely a USB stick, or
- /dev/mmcblk0, which is most likely an
- SD card.
-
- Boot the Hardware:
- With the boot device provisioned, you can insert the
- media into the MinnowBoard MAX and boot the hardware.
- The board should automatically detect the media and boot to
- the bootloader and subsequently the operating system.
-
+
+ In the previous command, the
+ TARGET_DEVICE is the device node in
+ the host machine (e.g. /dev/sdc, which
+ is most likely a USB stick, or
+ /dev/mmcblk0, which is most likely an
+ SD card.
+
+ Boot the Hardware:
+ With the boot device provisioned, you can insert the
+ media into the MinnowBoard MAX and boot the hardware.
+ The board should automatically detect the media and boot to
+ the bootloader and subsequently the operating system.
+
- If the board does not boot automatically, you can
- boot it manually from the EFI shell as follows:
-
+ If the board does not boot automatically, you can
+ boot it manually from the EFI shell as follows:
+
Shell> connect -r
Shell> map -r
Shell> fs0:
Shell> bootx64
-
-
- For a 32-bit image use the following:
-
- Shell> bootia32
-
-
-
-
+
+ For a 32-bit image use the following:
+
+ Shell> bootia32
+
+
+
+
+
+