diff --git a/documentation/Makefile b/documentation/Makefile
index 9891095043..a747b44738 100644
--- a/documentation/Makefile
+++ b/documentation/Makefile
@@ -141,10 +141,15 @@ STYLESHEET = $(DOC)/*.css
endif
ifeq ($(DOC),yocto-project-qs)
-XSLTOPTS = --xinclude
+XSLTOPTS = --stringparam html.stylesheet qs-style.css \
+ --stringparam chapter.autolabel 1 \
+ --stringparam section.autolabel 1 \
+ --stringparam section.label.includes.component.label 1 \
+ --xinclude
ALLPREQ = html eclipse tarball
+
TARFILES = yocto-project-qs.html qs-style.css \
- figures/yocto-project-transp.png \
+ figures/yocto-project-transp.png figures/ypqs-title.png \
eclipse
MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse
FIGURES = figures
@@ -244,7 +249,7 @@ TARFILES = mega-manual.html mega-style.css \
figures/sdk-environment.png figures/sdk-installed-standard-sdk-directory.png \
figures/sdk-devtool-add-flow.png figures/sdk-installed-extensible-sdk-directory.png \
figures/sdk-devtool-modify-flow.png figures/sdk-eclipse-dev-flow.png \
- figures/sdk-devtool-upgrade-flow.png figures/bitbake-build-flow.png
+ figures/sdk-devtool-upgrade-flow.png figures/bitbake-build-flow.png figures/ypqs-title.png
endif
MANUALS = $(DOC)/$(DOC).html
diff --git a/documentation/mega-manual/figures/ypqs-title.png b/documentation/mega-manual/figures/ypqs-title.png
new file mode 100644
index 0000000000..25c7a42b99
Binary files /dev/null and b/documentation/mega-manual/figures/ypqs-title.png differ
diff --git a/documentation/mega-manual/mega-manual.xml b/documentation/mega-manual/mega-manual.xml
index 51630f8151..3557cae84b 100644
--- a/documentation/mega-manual/mega-manual.xml
+++ b/documentation/mega-manual/mega-manual.xml
@@ -122,8 +122,12 @@
+
+
+
+
+ xmlns:xi="http://www.w3.org/2003/XInclude" href="../yocto-project-qs/qs.xml"/>
diff --git a/documentation/yocto-project-qs/figures/ypqs-title.png b/documentation/yocto-project-qs/figures/ypqs-title.png
new file mode 100644
index 0000000000..25c7a42b99
Binary files /dev/null and b/documentation/yocto-project-qs/figures/ypqs-title.png differ
diff --git a/documentation/yocto-project-qs/qs-style.css b/documentation/yocto-project-qs/qs-style.css
index 948f1bed3f..5085b9d0be 100644
--- a/documentation/yocto-project-qs/qs-style.css
+++ b/documentation/yocto-project-qs/qs-style.css
@@ -118,12 +118,13 @@ h6 {
background-color: transparent;
background-repeat: no-repeat;
padding-top: 256px;
- background-position: top;
+ background-image: url("figures/ypqs-title.png");
+ background-position: left top;
margin-top: -256px;
padding-right: 50px;
- margin-left: 50px;
- text-align: center;
- width: 600px;
+ margin-left: 0px;
+ text-align: right;
+ width: 740px;
}
h3.author {
@@ -791,9 +792,9 @@ div.article .titlepage .title
div.preface .titlepage .title,
div.colophon .title,
-div.chapter .titlepage .title,
-div.article .titlepage .title
-{
+div.chapter .titlepage .title {
+ background-position: bottom;
+ background-repeat: repeat-x;
}
div.section div.section .titlepage .title,
diff --git a/documentation/yocto-project-qs/qs.xml b/documentation/yocto-project-qs/qs.xml
new file mode 100644
index 0000000000..4dc6141a9d
--- /dev/null
+++ b/documentation/yocto-project-qs/qs.xml
@@ -0,0 +1,1116 @@
+ %poky; ] >
+
+
+
+
+ Welcome!
+
+
+ Welcome to the Yocto Project!
+ The Yocto Project is an open-source collaboration project whose
+ focus is developers of embedded Linux systems.
+ The Yocto Project provides a development
+ environment that eases application, kernel image, and Linux image
+ development for embedded hardware systems.
+ You can think of the Yocto Project as an umbrella over-arching
+ many components, which include a build system, a reference or
+ test distribution, and various tools all designed to enhance
+ your embedded Linux development experience.
+
+
+
+ The Yocto Project uses a build host based on the OpenEmbedded
+ (OE) project, which uses the
+ BitBake
+ tool, to construct complete images.
+ The BitBake and OE components combine together to form
+ a reference build host, historically known as
+ Poky
+ (Pah-kee).
+ Tools exist that facilitate aspects of development such as
+ layer creation to isolate your work, emulation for testing
+ modules, modification of existing source code, integration of
+ new or modified modules into existing images, and so forth.
+
+
+
+ Rather than go into great detail about the Yocto Project and its
+ many capabilities, this quick start provides high-level
+ practical information that lets you try out the Yocto Project.
+ The quick start is written to help introduce you to the Yocto
+ Project, get a feel for how to use it to build a Linux image or
+ two, and provide you with a "road map" to other areas of interest
+ for the new user.
+ Tips
+
+
+ For more introductory and conceptual information on the
+ Yocto Project, see the Yocto Project Overview Manual.
+
+
+ For guidance on where to look for information beyond
+ this quick start, see the
+ "Where To Go Next"
+ section.
+
+
+
+
+
+
+
+ Reference Build
+
+
+ This section of the quick start lets you work through setting up
+ a build host and then shows you how to build two images: one for
+ emulation and one for target hardware.
+ The steps do not go into great detail but are rather focused on
+ just letting you get set up and quickly experience the Yocto
+ Project.
+
+
+
+ Setting Up to Use the Yocto Project
+
+
+ Setting up to use the Yocto Project involves getting your build
+ host ready.
+ If you have a native Linux machine that runs a Yocto Project
+ supported distribution as described by the
+ "Supported Linux Distributions"
+ section in the Yocto Project Reference Manual, you can prepare
+ that machine as your build host.
+ See the
+ "Using a Native Linux Machine"
+ section for more information.
+
+
+
+ If you do not want to use the Yocto Project on a native Linux
+ machine, you can prepare your build host to use
+ CROPS,
+ which leverages
+ Docker Containers.
+ You can set up a build host for Windows, Mac, and Linux
+ machines.
+ See the
+ "Using CROPS and Containers"
+ section for more information.
+
+
+
+ Using CROPS and Containers
+
+
+ Follow these steps to get your build host set up with a
+ Poky container that you can use to complete the build
+ examples further down in the Quick Start:
+
+
+ Set Up to use CROss PlatformS (CROPS):
+ Work through the first six steps of the procedure
+ in the
+ "Setting Up to Use CROss PlatformS (CROPS)"
+ section of the Yocto Project Development Tasks Manual.
+
+
+ Set Up the Poky Container to Use the Yocto Project:
+ Go to
+
+ and follow the directions to set up the Poky container
+ on your build host.
+
+ Once you complete the setup instructions for your
+ machine, you need to get a copy of the
+ poky repository on your build
+ host.
+ See the
+ "Yocto Project Release"
+ section to continue.
+
+
+
+
+
+
+ Using a Native Linux Machine
+
+
+ The following list shows what you need in order to use a
+ Linux-based build host to use the Yocto Project to build images:
+
+
+
+ Build Host
+ A build host with a minimum of 50 Gbytes of free disk
+ space that is running a supported Linux distribution (i.e.
+ recent releases of Fedora, openSUSE, CentOS, Debian, or
+ Ubuntu).
+
+ Build Host Packages
+ Appropriate packages installed on the build host.
+
+
+
+
+ The Linux Distribution
+
+
+ The Yocto Project team verifies each release against recent
+ versions of the most popular Linux distributions that
+ provide stable releases.
+ In general, if you have the current release minus one of the
+ following distributions, you should have no problems.
+
+
+ Ubuntu
+
+
+ Fedora
+
+
+ openSUSE
+
+
+ CentOS
+
+
+ Debian
+
+
+ For a more detailed list of distributions that support the
+ Yocto Project, see the
+ "Supported Linux Distributions"
+ section in the Yocto Project Reference Manual.
+
+
+
+ The OpenEmbedded build system should be able to run on any
+ modern distribution that has the following versions for
+ Git, tar, and Python.
+
+
+ Git 1.8.3.1 or greater
+
+
+ tar 1.27 or greater
+
+
+ Python 3.4.0 or greater.
+
+
+ If your build host does not meet any of these three listed
+ version requirements, you can take steps to prepare the
+ system so that you can still use the Yocto Project.
+ See the
+ "Required Git, tar, and Python Versions"
+ section in the Yocto Project Reference Manual for information.
+
+
+
+
+ The Build Host Packages
+
+
+ Required build host packages vary depending on your
+ build machine and what you want to do with the Yocto Project.
+ For example, if you want to build an image that can run
+ on QEMU in graphical mode (a minimal, basic build
+ requirement), then the build host package requirements
+ are different than if you want to build an image on a headless
+ system or build out the Yocto Project documentation set.
+
+
+
+ Collectively, the number of required packages is large
+ if you want to be able to cover all cases.
+
+ In general, you need to have root access and then install
+ the required packages.
+ Thus, the commands in the following section may or may
+ not work depending on whether or not your Linux
+ distribution has sudo installed.
+
+
+
+
+ The following list shows the required packages needed to build
+ an image that runs on QEMU in graphical mode (e.g. essential
+ plus graphics support).
+ For lists of required packages for other scenarios, see the
+ "Required Packages for the Host Development System"
+ section in the Yocto Project Reference Manual.
+
+ Ubuntu and Debian
+
+ $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; libsdl1.2-dev xterm
+
+
+ Fedora
+
+ $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
+
+
+ OpenSUSE
+
+ $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL; libSDL-devel xterm
+
+
+ CentOS
+
+ $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
+
+ Notes
+
+
+ CentOS 6.x users need to ensure that the
+ required versions of Git, tar and Python
+ are available.
+ For details, See the
+ "Required Git, tar, and Python Versions"
+ section in the Yocto Project Reference
+ Manual for information.
+
+
+ Extra Packages for Enterprise Linux
+ (i.e. epel-release)
+ is a collection of packages from Fedora
+ built on RHEL/CentOS for easy installation
+ of packages not included in enterprise
+ Linux by default.
+ You need to install these packages
+ separately.
+
+
+ The makecache command
+ consumes additional Metadata from
+ epel-release.
+
+
+
+
+
+
+
+
+
+ Once you complete the setup instructions for your
+ machine, you need to get a copy of the
+ poky repository on your build
+ host.
+ Continue with the
+ "Yocto Project Release"
+ section.
+
+
+
+
+ Yocto Project Release
+
+
+ Now that your build host has the right packages (native
+ Linux machine) or you have the Poky container set up
+ (CROPS), you need to get a copy of the Yocto Project.
+ It is recommended that you get the latest Yocto Project release
+ by setting up (cloning in
+ Git terms) a
+ local copy of the poky Git repository on
+ your build host and then checking out the latest release.
+ Doing so allows you to easily update to newer Yocto Project
+ releases as well as contribute back to the Yocto Project.
+
+
+
+ Here is an example from a native Linux machine that is
+ running Ubuntu.
+
+ If your build host is using a Poky container, you can
+ use the same Git commands.
+
+ The following example clones the poky
+ repository and then checks out the latest Yocto Project Release
+ by tag (i.e. &DISTRO_REL_TAG;):
+
+ $ git clone git://git.yoctoproject.org/poky
+ Cloning into 'poky'...
+ remote: Counting objects: 361782, done.
+ remote: Compressing objects: 100% (87100/87100), done.
+ remote: Total 361782 (delta 268619), reused 361439 (delta 268277)
+ Receiving objects: 100% (361782/361782), 131.94 MiB | 6.88 MiB/s, done.
+ Resolving deltas: 100% (268619/268619), done.
+ Checking connectivity... done.
+ $ git checkout tags/&DISTRO_REL_TAG; -b poky_&DISTRO;
+
+
+
+
+ The previous Git checkout command
+ creates a local branch named
+ poky_&DISTRO;.
+ The files available to you in that branch exactly match the
+ repository's files in the
+ &DISTRO_NAME_NO_CAP;
+ development branch at the time of the Yocto Project &DISTRO;
+ release.
+
+ Rather than checking out the entire development branch
+ of a release (i.e. the tip), which could be continuously
+ changing while you are doing your development, you would
+ check out a branch based on a release tag as shown in
+ the previous example.
+ Doing so provides you with an unchanging, stable set of
+ files.
+
+
+
+
+ For more options and information about accessing Yocto
+ Project related repositories, see the
+ "Working With Yocto Project Source Files"
+ section in the Yocto Project Development Tasks Manual.
+
+
+
+
+
+ Building Images
+
+
+ You are now ready to give the Yocto Project a try.
+ For this example, you will be using the command line to build
+ your images.
+
+ A graphical user interface to the Yocto Project is available
+ through
+ Toaster.
+ See the
+ Toaster User Manual
+ for more information.
+
+
+
+
+ The remainder of this quick start steps you through the
+ following:
+
+
+ Build a qemux86 reference image
+ and run it in the QEMU emulator.
+
+
+ Easily change configurations so that you can quickly
+ create a second image that you can load onto bootable
+ media and actually boot target hardware.
+ This example uses the MinnowBoard
+ Turbot-compatible boards.
+
+
+
+ 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.
+
+
+
+
+ Building an Image for Emulation
+
+
+ Use the following commands to build your image.
+ The OpenEmbedded build system creates an entire Linux
+ distribution, including the toolchain, from source.
+ Notes 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).
+
+
+ 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.
+
+ $ 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.
+
+
+ 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.
+
+
+ $ bitbake core-image-sato
+
+
+
+ If you experience a build error due to resources
+ temporarily being unavailable and it appears you
+ should not be having this issue, it might be due
+ to the combination of a 4.3+ Linux kernel and
+ systemd version 228+
+ (i.e. see this
+ link
+ for information).
+
+
+
+ To work around this issue, you can try either
+ of the following:
+
+
+ Try the build again.
+
+
+ Modify the "DefaultTasksMax"
+ systemd parameter
+ by uncommenting it and setting it to
+ "infinity".
+ You can find this parameter in the
+ system.conf file
+ located in
+ /etc/systemd
+ on most systems.
+
+
+
+
+ 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 Tasks Manual.
+
+
+ Exit QEMU:
+ Exit QEMU by either clicking on the shutdown icon or by
+ typing Ctrl-C in the QEMU
+ transcript window from which you evoked QEMU.
+
+
+
+
+
+
+ Building an Image for Hardware
+
+
+ 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 Turbot, which is
+ supported by the Yocto Project and the
+ meta-intel intel-corei7-64
+ and intel-core2-32 Board Support Packages
+ (BSPs).
+
+ The MinnowBoard Turbot 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 Turbot 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'...
+ remote: Counting objects: 14039, done.
+ remote: Compressing objects: 100% (4471/4471), done.
+ remote: Total 14039 (delta 8130), reused 13837 (delta 7947)
+ Receiving objects: 100% (14039/14039), 4.27 MiB | 3.98 MiB/s, done.
+ Resolving deltas: 100% (8130/8130), 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.
+ Because you used the &DISTRO_REL_TAG;
+ tag when you checked out the poky
+ repository by tag, you should use a
+ meta-intel
+ tag that corresponds with the release you used for
+ poky.
+ Consequently, you need to checkout out the
+ "&METAINTELVERSION;-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;"
+ branch after cloning meta-intel:
+
+ $ cd $HOME/poky/meta-intel
+ $ git checkout tags/&METAINTELVERSION;-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION; -b meta-intel-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;
+ Switched to a new branch 'meta-intel-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;'
+
+ The previous Git checkout command
+ creates a local branch named
+ meta-intel-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;.
+ You have the option to name your local branch whatever
+ you want by providing any name you like for
+ "meta-intel-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;"
+ in the above example.
+
+
+ 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.
+
+ $ 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:
+
+ $ echo 'MACHINE = "intel-corei7-64"' >> conf/local.conf
+
+
+
+
+ If you want 32-bit images, use the following:
+
+ $ echo 'MACHINE = "intel-core2-32"' >> conf/local.conf
+
+
+
+
+
+ Build an Image for MinnowBoard
+ Turbot:
+ 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 Turbot.
+ 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
+
+
+
+ If you experience a build error due to resources
+ temporarily being unavailable and it appears you
+ should not be having this issue, it might be due
+ to the combination of a 4.3+ Linux kernel and
+ systemd version 228+
+ (i.e. see this
+ link
+ for information).
+
+
+
+ To work around this issue, you can try either
+ of the following:
+
+
+ Try the build again.
+
+
+ Modify the "DefaultTasksMax"
+ systemd parameter
+ by uncommenting it and setting it to
+ "infinity".
+ You can find this parameter in the
+ system.conf file
+ located in
+ /etc/systemd
+ on most systems.
+
+
+
+
+ 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.wic
+
+
+
+ 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-base-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 Turbot 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:
+
+ Shell> connect -r
+ Shell> map -r
+ Shell> fs0:
+ Shell> bootx64
+
+
+ For a 32-bit image use the following:
+
+ Shell> bootia32
+
+
+
+
+
+
+
+
+
+
+ Where To Go Next
+
+
+ Now that you have experienced using the Yocto Project, you might
+ be asking yourself "What now?"
+ This next section of the Quick Start provides some "sign posts"
+ that can help you find additional information depending on what
+ you want to accomplish with the Yocto Project.
+ The section provides a list of resources for more information,
+ some links into sections that provide basic tasks, and some
+ links into more specialized areas that go beyond building images.
+
+ You can also see the
+ page for
+ suggested sets of Yocto Project manuals designed for various
+ levels of experience.
+
+
+
+
+ Additional Resources
+
+
+ The Yocto Project has many sources of information including
+ the website, wiki pages, and user manuals.
+ This section lists resources you might find helpful:
+
+
+ Website:
+ The
+ Yocto Project Website
+ provides background information, the latest builds,
+ breaking news, full development documentation, and
+ access to a rich Yocto Project Development Community
+ into which you can tap.
+
+
+ FAQs:
+ Lists commonly asked Yocto Project questions and
+ answers.
+ You can find two FAQs:
+ Yocto Project FAQ
+ on a wiki, and the
+ "FAQ"
+ chapter in the Yocto Project Reference Manual.
+
+
+ Developer Screencast:
+ The
+ Getting Started with the Yocto Project - New Developer Screencast Tutorial
+ provides a 30-minute video created for users unfamiliar
+ with the Yocto Project but familiar with Linux build
+ hosts.
+ While this screencast is somewhat dated, the
+ introductory and fundamental concepts are useful for
+ the beginner.
+
+
+ Yocto Project Implementation of Bugzilla:
+ The Yocto Project uses its own implementation of
+ Bugzilla that you can find
+ here.
+ Bugzilla allows you to report and track the progress
+ of defects and improvements to the Yocto Project.
+
+
+ Yocto Project Wiki:
+ The
+ Yocto Project Wiki
+ provides additional information on where to go next
+ when ramping up with the Yocto Project, release
+ information, project planning, and QA information.
+
+
+ Yocto Project Mailing Lists:
+ Related mailing lists provide a forum for discussion,
+ patch submission and announcements.
+ Several mailing lists exist and are grouped according
+ to areas of concern.
+ See the
+ "Mailing lists"
+ section in the Yocto Project Reference Manual for a
+ complete list of Yocto Project mailing lists.
+
+
+ Comprehensive List of Links and Other Documentation:
+ The
+ "Links and Related Documentation"
+ section in the Yocto Project Reference Manual provides a
+ comprehensive list of all related links and other
+ user documentation.
+
+
+
+
+
+
+ Guided Examples
+
+
+ Depending on what you primary interests are with the Yocto
+ Project, you could consider any of the following:
+
+
+ Add a Layer for Hardware Support:
+ For steps on how to add a Board Support Package (BSP)
+ layer that supports specific hardware, see the
+ "Creating a new BSP Layer Using the yocto-bsp Script"
+ section in the Yocto Project Board Support Package
+ (BSP) Developer's Guide.
+ For background information on BSP layers, see the
+ "BSP Layers"
+ section in the same manual.
+
+
+ Add a Layer for Software:
+ For steps on how to add a general layer for software,
+ see the
+ "Creating a General Layer Using the bitbake-layers Script"
+ section in the Yocto Project Development Tasks Manual.
+ For background information on layers in general, see the
+ "Understanding and Creating Layers"
+ section in the same manual.
+
+
+ Write a New Recipe:
+ For steps on how to write a new recipe,
+ see the
+ "Writing a New Recipe"
+ section in the Yocto Project Development Tasks Manual.
+
+
+ Create a Layer for Customizations:
+ This is a step suggested by Richard.
+ I don't know the distinction between creating a layer
+ for customizations and creating a general layer as
+ pointed out earlier for creating a general layer
+ (i.e. a layer for software).
+ I need some help on this bullet item.
+
+
+ Add a Custom Kernel:
+ For steps on how to modify and create your own custom
+ kernel, see the
+ "Using devtool to Patch the Kernel"
+ section in the Yocto Project Linux Kernel Development
+ Manual.
+
+
+ Change the Default Kernel Configuration:
+ For steps on how to configure the kernel, see the
+ "Configuring the Kernel"
+ section in the Yocto Project Linux Kernel Development
+ Manual.
+
+
+ Submit a Change to the Yocto Project:
+ For steps on how to submit a change or patch to the
+ Yocto Project, see the
+ "Submitting a Change to the Yocto Project"
+ section in the Yocto Project Development Tasks Manual.
+
+
+
+
+
+
+ Going Beyond Builds
+
+
+ This section presents some pointers to topics that go beyond
+ building images:
+
+
+ The OpenEmbedded Layer Index:
+ This index shows layers that exist for use with the
+ Yocto Project.
+ More times than not, you can find layers for your own
+ use or layers that are close to what you need and can
+ be leveraged when creating your own layers.
+ See
+ http://layers.openembedded.org/layerindex/branch/master/layers/
+ for the layer index.
+
+
+ Yocto Project Autobuilder:
+ Autobuilders provide automatic building in a
+ development or production environment.
+ For information on the autobuilders used by the Yocto
+ Project, see the
+ "Setting Up a Team Yocto Project Development Environment"
+ section of the Yocto Project Development Tasks Manual.
+ You can also see the
+ http://autobuilder.yoctoproject.org/
+ link.
+
+
+ Yocto Project Compatibility:
+ When you create layers, you can take steps to make sure
+ your layer is compatible with the Yocto Project.
+ See the
+ "Making Sure Your Layer is Compatible With Yocto Project"
+ section in the Yocto Project Development Tasks Manual
+ for more information.
+
+
+ Auto Upgrade Tools:
+ This is a step suggested by Richard.
+ I don't know what this is and need help with this
+ bullet item.
+
+
+ Patches and Patchwork:
+ This is a step suggested by Richard.
+ I don't know what this is and need help with this
+ bullet item.
+
+
+ Pseudo:
+ Pseudo gives the illusion of running under root and is
+ is used during the image generation process.
+ I don't have much on this in the manual set.
+ Is there any more information we can leverage?
+ For information on Fakeroot and Pseudo, see the
+ "Fakeroot and Pseudo"
+ section in the Yocto Project Reference Manual.
+
+
+ OPKG:
+ OPKG is a file management system.
+ I am not sure what Richard had in mind for suggesting
+ this "beyond builds" topic.
+ I have one reference at
+ "Using IPK"
+ in the Yocto Project Development Tasks Manual that
+ is the bulk of my known information.
+ I need more help with this bullet item.
+
+
+ Team Yocto Project Development Environments:
+ For information on Yocto Project development team
+ environments, see the
+ "Setting Up a Team Yocto Project Development Environment"
+ section in the Yocto Project Development Tasks Manual.
+
+
+
+
+
+
+
diff --git a/documentation/yocto-project-qs/yocto-project-qs-customization.xsl b/documentation/yocto-project-qs/yocto-project-qs-customization.xsl
index dcc02dd370..3372c7a7c3 100644
--- a/documentation/yocto-project-qs/yocto-project-qs-customization.xsl
+++ b/documentation/yocto-project-qs/yocto-project-qs-customization.xsl
@@ -19,6 +19,19 @@
+
+
+
+
+
+
+
+
+
+
diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml
index cfaa70f551..12ca05b930 100644
--- a/documentation/yocto-project-qs/yocto-project-qs.xml
+++ b/documentation/yocto-project-qs/yocto-project-qs.xml
@@ -1,21 +1,140 @@
- %poky; ] >
-
-
- Yocto Project Quick Start
+
+
-
- ©RIGHT_YEAR;
- Linux Foundation
-
+
+
+
+
+
-
-
- Permission is granted to copy, distribute and/or modify this document under
- the terms of the Creative Commons Attribution-Share Alike 2.0 UK: England & Wales as published by Creative Commons.
-
+
+ Yocto Project Quick Start
+
+
+
+
+ Scott Rifenbark
+
+ Scotty's Documentation Services, INC
+
+ srifenbark@gmail.com
+
+
+
+
+
+
+ ©RIGHT_YEAR;
+ Linux Foundation
+
+
+
+
+ Permission is granted to copy, distribute and/or modify this document under
+ the terms of the Creative Commons Attribution-Share Alike 2.0 UK: England & Wales as published by Creative Commons.
+
Manual Notes
@@ -44,1022 +163,18 @@
-
+
-
-
-
-
+
-
- Welcome!
-
- Welcome to the Yocto Project!
- The Yocto Project is an open-source collaboration project whose
- focus is developers of embedded Linux systems.
- Among other things, the Yocto Project uses a build host based
- on the OpenEmbedded (OE) project, which uses the
- BitBake
- tool, to construct complete Linux images.
- The BitBake and OE components combine together to form
- a reference build host, historically known as
- Poky
- (Pah-kee).
-
+
-
- This quick start is written so that you can quickly get a
- build host set up to use the Yocto Project and then build some
- Linux images.
- Rather than go into great detail about the Yocto Project and its
- many capabilities, this quick start provides the minimal
- information you need to try out the Yocto Project using either a
- supported Linux build host or a build host set up to use
- CROPS,
- which leverages
- Docker Containers.
-
-
-
- Reading and using the quick start should result in you having a
- basic understanding of what the Yocto Project is and how to use
- some of its core components.
- You will also have worked through steps to produce two images:
- one that runs on the emulator (QEMU) and one that boots on actual
- hardware (i.e. MinnowBoard Turbot).
- The examples highlight the ease with which you can use the
- Yocto Project to create images for multiple types of hardware.
-
-
-
- The following list directs you to key sections of this
- quick start:
-
-
- Setting Up to Use the Yocto Project
-
-
- Building an Image for Emulation
-
-
- Building an Image for Hardware
-
-
-
-
-
- For more detailed information on the Yocto Project, you can
- reference these resources:
-
-
- Website:
- The
- Yocto Project Website
- provides bacground information, the latest builds, breaking
- news, full development documentation, and access to a rich
- Yocto Project Development Community into which you can tap.
-
-
- Yocto Project Development Environment Overview:
- The
- "Introducing the Yocto Project Development Environment"
- section presents an overview of the Yocto Project
- development environment.
-
-
- FAQs:
- Lists commonly asked Yocto Project questions and answers.
- You can find two FAQs:
- Yocto Project FAQ
- on a wiki, and the
- "FAQ"
- chapter in the Yocto Project Reference Manual.
-
-
- Developer Screencast:
- The
- Getting Started with the Yocto Project - New Developer Screencast Tutorial
- provides a 30-minute video created for users unfamiliar
- with the Yocto Project but familiar with Linux build
- hosts.
- While this screencast is somewhat dated, the introductory
- and fundamental concepts are useful for the beginner.
-
-
- Comprehensive List of Links and Other Documentation:
- The
- "Links and Related Documentation"
- section in the Yocto Project Reference Manual provides a
- comprehensive list of related links and documentation.
-
-
-
-
-
-
- Setting Up to Use the Yocto Project
-
-
- Setting up to use the Yocto Project involves getting your build
- host ready.
- If you have a native Linux machine that runs a Yocto Project
- supported distribution as described by the
- "Supported Linux Distributions"
- section in the Yocto Project Reference Manual, you can prepare
- that machine as your build host.
- See the
- "Using a Native Linux Machine"
- section for more information.
-
-
-
- If you do not want to use the Yocto Project on a native Linux
- machine, you can prepare your build host to use
- CROPS,
- which leverages
- Docker Containers.
- You can set up a build host for Windows, Mac, and Linux
- machines.
- See the
- "Using CROPS and Containers"
- section for more information.
-
-
-
- Using CROPS and Containers
-
-
- Follow these steps to get your build host set up with a
- Poky container that you can use to complete the build
- examples further down in the Quick Start:
-
-
- Set Up to use CROss PlatformS (CROPS):
- Work through the first six steps of the procedure
- in the
- "Setting Up to Use CROss PlatformS (CROPS)"
- section of the Yocto Project Development Tasks Manual.
-
-
- Set Up the Poky Container to Use the Yocto Project:
- Go to
-
- and follow the directions to set up the Poky container
- on your build host.
-
- Once you complete the setup instructions for your
- machine, you need to get a copy of the
- poky repository on your build
- host.
- See the
- "Yocto Project Release"
- section to continue.
-
-
-
-
-
-
- Using a Native Linux Machine
-
-
- The following list shows what you need in order to use a
- Linux-based build host to use the Yocto Project to build images:
-
-
-
- Build Host
- A build host with a minimum of 50 Gbytes of free disk
- space that is running a supported Linux distribution (i.e.
- recent releases of Fedora, openSUSE, CentOS, Debian, or
- Ubuntu).
-
- Build Host Packages
- Appropriate packages installed on the build host.
-
-
-
-
- The Linux Distribution
-
-
- The Yocto Project team verifies each release against recent
- versions of the most popular Linux distributions that
- provide stable releases.
- In general, if you have the current release minus one of the
- following distributions, you should have no problems.
-
-
- Ubuntu
-
-
- Fedora
-
-
- openSUSE
-
-
- CentOS
-
-
- Debian
-
-
- For a more detailed list of distributions that support the
- Yocto Project, see the
- "Supported Linux Distributions"
- section in the Yocto Project Reference Manual.
-
-
-
- The OpenEmbedded build system should be able to run on any
- modern distribution that has the following versions for
- Git, tar, and Python.
-
-
- Git 1.8.3.1 or greater
-
-
- tar 1.27 or greater
-
-
- Python 3.4.0 or greater.
-
-
- If your build host does not meet any of these three listed
- version requirements, you can take steps to prepare the
- system so that you can still use the Yocto Project.
- See the
- "Required Git, tar, and Python Versions"
- section in the Yocto Project Reference Manual for information.
-
-
-
-
- The Build Host Packages
-
-
- Required build host packages vary depending on your
- build machine and what you want to do with the Yocto Project.
- For example, if you want to build an image that can run
- on QEMU in graphical mode (a minimal, basic build
- requirement), then the build host package requirements
- are different than if you want to build an image on a headless
- system or build out the Yocto Project documentation set.
-
-
-
- Collectively, the number of required packages is large
- if you want to be able to cover all cases.
-
- In general, you need to have root access and then install
- the required packages.
- Thus, the commands in the following section may or may
- not work depending on whether or not your Linux
- distribution has sudo installed.
-
-
-
-
- The following list shows the required packages needed to build
- an image that runs on QEMU in graphical mode (e.g. essential
- plus graphics support).
- For lists of required packages for other scenarios, see the
- "Required Packages for the Host Development System"
- section in the Yocto Project Reference Manual.
-
- Ubuntu and Debian
-
- $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; libsdl1.2-dev xterm
-
-
- Fedora
-
- $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
-
-
- OpenSUSE
-
- $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL; libSDL-devel xterm
-
-
- CentOS
-
- $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
-
- Notes
-
-
- CentOS 6.x users need to ensure that the
- required versions of Git, tar and Python
- are available.
- For details, See the
- "Required Git, tar, and Python Versions"
- section in the Yocto Project Reference
- Manual for information.
-
-
- Extra Packages for Enterprise Linux
- (i.e. epel-release)
- is a collection of packages from Fedora
- built on RHEL/CentOS for easy installation
- of packages not included in enterprise
- Linux by default.
- You need to install these packages
- separately.
-
-
- The makecache command
- consumes additional Metadata from
- epel-release.
-
-
-
-
-
-
-
-
-
- Once you complete the setup instructions for your
- machine, you need to get a copy of the
- poky repository on your build
- host.
- Continue with the
- "Yocto Project Release"
- section.
-
-
-
-
- Yocto Project Release
-
-
- Now that your build host has the right packages (native
- Linux machine) or you have the Poky container set up
- (CROPS), you need to get a copy of the Yocto Project.
- It is recommended that you get the latest Yocto Project release
- by setting up (cloning in
- Git terms) a
- local copy of the poky Git repository on
- your build host and then checking out the latest release.
- Doing so allows you to easily update to newer Yocto Project
- releases as well as contribute back to the Yocto Project.
-
-
-
- Here is an example from a native Linux machine that is
- running Ubuntu.
-
- If your build host is using a Poky container, you can
- use the same Git commands.
-
- The following example clones the poky
- repository and then checks out the latest Yocto Project Release
- by tag (i.e. &DISTRO_REL_TAG;):
-
- $ git clone git://git.yoctoproject.org/poky
- Cloning into 'poky'...
- remote: Counting objects: 361782, done.
- remote: Compressing objects: 100% (87100/87100), done.
- remote: Total 361782 (delta 268619), reused 361439 (delta 268277)
- Receiving objects: 100% (361782/361782), 131.94 MiB | 6.88 MiB/s, done.
- Resolving deltas: 100% (268619/268619), done.
- Checking connectivity... done.
- $ git checkout tags/&DISTRO_REL_TAG; -b poky_&DISTRO;
-
-
-
-
- The previous Git checkout command
- creates a local branch named
- poky_&DISTRO;.
- The files available to you in that branch exactly match the
- repository's files in the
- &DISTRO_NAME_NO_CAP;
- development branch at the time of the Yocto Project &DISTRO;
- release.
-
- Rather than checking out the entire development branch
- of a release (i.e. the tip), which could be continuously
- changing while you are doing your development, you would
- check out a branch based on a release tag as shown in
- the previous example.
- Doing so provides you with an unchanging, stable set of
- files.
-
-
-
-
- For more options and information about accessing Yocto
- Project related repositories, see the
- "Working With Yocto Project Source Files"
- section in the Yocto Project Development Tasks Manual.
-
-
-
-
-
- Building Images
-
-
- You are now ready to give the Yocto Project a try.
- For this example, you will be using the command line to build
- your images.
-
- A graphical user interface to the Yocto Project is available
- through
- Toaster.
- See the
- Toaster User Manual
- for more information.
-
-
-
-
- The remainder of this quick start steps you through the
- following:
-
-
- Build a qemux86 reference image
- and run it in the QEMU emulator.
-
-
- Easily change configurations so that you can quickly
- create a second image that you can load onto bootable
- media and actually boot target hardware.
- This example uses the MinnowBoard
- Turbot-compatible boards.
-
-
-
- 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.
-
-
-
-
- Building an Image for Emulation
-
-
- Use the following commands to build your image.
- The OpenEmbedded build system creates an entire Linux
- distribution, including the toolchain, from source.
- Notes 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).
-
-
- 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.
-
- $ 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.
-
-
- 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.
-
-
- $ bitbake core-image-sato
-
-
-
- If you experience a build error due to resources
- temporarily being unavailable and it appears you
- should not be having this issue, it might be due
- to the combination of a 4.3+ Linux kernel and
- systemd version 228+
- (i.e. see this
- link
- for information).
-
-
-
- To work around this issue, you can try either
- of the following:
-
-
- Try the build again.
-
-
- Modify the "DefaultTasksMax"
- systemd parameter
- by uncommenting it and setting it to
- "infinity".
- You can find this parameter in the
- system.conf file
- located in
- /etc/systemd
- on most systems.
-
-
-
-
- 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 Tasks Manual.
-
-
- Exit QEMU:
- Exit QEMU by either clicking on the shutdown icon or by
- typing Ctrl-C in the QEMU
- transcript window from which you evoked QEMU.
-
-
-
-
-
-
- Building an Image for Hardware
-
-
- 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 Turbot, which is
- supported by the Yocto Project and the
- meta-intel intel-corei7-64
- and intel-core2-32 Board Support Packages
- (BSPs).
-
- The MinnowBoard Turbot 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 Turbot 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'...
- remote: Counting objects: 14039, done.
- remote: Compressing objects: 100% (4471/4471), done.
- remote: Total 14039 (delta 8130), reused 13837 (delta 7947)
- Receiving objects: 100% (14039/14039), 4.27 MiB | 3.98 MiB/s, done.
- Resolving deltas: 100% (8130/8130), 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.
- Because you used the &DISTRO_REL_TAG;
- tag when you checked out the poky
- repository by tag, you should use a
- meta-intel
- tag that corresponds with the release you used for
- poky.
- Consequently, you need to checkout out the
- "&METAINTELVERSION;-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;"
- branch after cloning meta-intel:
-
- $ cd $HOME/poky/meta-intel
- $ git checkout tags/&METAINTELVERSION;-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION; -b meta-intel-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;
- Switched to a new branch 'meta-intel-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;'
-
- The previous Git checkout command
- creates a local branch named
- meta-intel-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;.
- You have the option to name your local branch whatever
- you want by providing any name you like for
- "meta-intel-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;"
- in the above example.
-
-
- 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.
-
- $ 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:
-
- $ echo 'MACHINE = "intel-corei7-64"' >> conf/local.conf
-
-
-
-
- If you want 32-bit images, use the following:
-
- $ echo 'MACHINE = "intel-core2-32"' >> conf/local.conf
-
-
-
-
-
- Build an Image for MinnowBoard
- Turbot:
- 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 Turbot.
- 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
-
-
-
- If you experience a build error due to resources
- temporarily being unavailable and it appears you
- should not be having this issue, it might be due
- to the combination of a 4.3+ Linux kernel and
- systemd version 228+
- (i.e. see this
- link
- for information).
-
-
-
- To work around this issue, you can try either
- of the following:
-
-
- Try the build again.
-
-
- Modify the "DefaultTasksMax"
- systemd parameter
- by uncommenting it and setting it to
- "infinity".
- You can find this parameter in the
- system.conf file
- located in
- /etc/systemd
- on most systems.
-
-
-
-
- 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.wic
-
-
-
- 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-base-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 Turbot 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:
-
- Shell> connect -r
- Shell> map -r
- Shell> fs0:
- Shell> bootx64
-
-
- For a 32-bit image use the following:
-
- Shell> bootia32
-
-
-
-
-
-
-
-
-
- Next Steps
-
-
- If you completed all the steps in the previous section then
- congratulations!
- What now?
-
-
-
- Depending on what you primary interests are with the Yocto Project,
- you could consider any of the following:
-
-
- Visit the Yocto Project Web Site:
- The official
- Yocto Project
- web site contains information on the entire project.
- Visiting this site is a good way to familiarize yourself
- with the overall project.
-
-
- Look Through the
- Yocto Project Development Tasks Manual:
- This manual contains procedural information grouped to
- help you get set up, work with layers, customize images,
- write new recipes, work with libraries, and use QEMU.
- The information is task-based and spans the breadth of the
- Yocto Project.
-
-
- Look Through the
- Yocto Project Application Development and the Extensible Software Development Kit (eSDK)
- manual:
- This manual describes how to use both the
- standard SDK
- and the
- extensible SDK,
- which are used primarily for application development.
- This manual also provides example workflows
- that use the popular Eclipse
- development environment and that use devtool.
- See the
- "Workflow using Eclipse™"
- and
- "Using devtool in your SDK Workflow"
- sections for more information.
-
-
- Learn About Kernel Development:
- If you want to see how to work with the kernel and
- understand Yocto Linux kernels, see the
- Yocto Project Linux Kernel Development Manual.
- This manual provides information on how to patch the
- kernel, modify kernel recipes, and configure the kernel.
-
-
- Learn About Board Support Packages (BSPs):
- If you want to learn about BSPs, see the
- Yocto Project Board Support Packages (BSP) Developer's Guide.
- This manual also provides an example BSP creation workflow.
- See the
- "Developing a Board Support Package (BSP)"
- section.
-
-
- Learn About Toaster:
- Toaster is a web interface to the Yocto Project's
- OpenEmbedded build system.
- If you are interested in using this type of interface to
- create images, see the
- Toaster User Manual.
-
-
- Have Available the
- Yocto Project Reference Manual:
- Unlike the rest of the Yocto Project manual set, this manual
- is comprised of material suited for reference rather than
- procedures.
- You can get
- build details,
- a
- closer look
- at how the pieces of the Yocto Project development
- environment work together, information on various
- technical details,
- guidance on
- migrating to a newer Yocto Project release,
- reference material on the
- directory structure,
- classes,
- and
- tasks.
- The Yocto Project Reference Manual also contains a fairly
- comprehensive
- glossary of variables
- used within the Yocto Project.
-
-
-
-
-
+