build-applance-image: Fix to use the release branch for morty

(From OE-Core rev: 2a59d0fa7bda78927435603e3049ce373cf6a198)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/dev-manual/dev-manual-common-tasks.xml

@@ -3621,6 +3621,106 @@
         </section>
     </section>
 
+    <section id='platdev-building-targets-with-multiple-configurations'>
+        <title>Building Targets with Multiple Configurations</title>
+
+        <para>
+            Bitbake also has functionality that allows you to build
+            multiple targets at the same time, where each target uses
+            a different configuration.
+        </para>
+
+        <para>
+            In order to accomplish this, you setup each of the configurations
+            you need to use in parallel by placing the configuration files in
+            your current build directory alongside the usual
+            <filename>local.conf</filename> file.
+        </para>
+
+        <para>
+            Follow these guidelines to create an environment that supports
+            multiple configurations:
+            <itemizedlist>
+                <listitem><para>
+                    <emphasis>Create Configuration Files</emphasis>:
+                    You need to create a single configuration file for each
+                    configuration for which you want to add support.
+                    These files would contain lines such as the following:
+                    <literallayout class='monospaced'>
+     MACHINE = "A"
+                    </literallayout>
+                    The files would contain any other variables that can
+                    be set and built in the same directory.
+                    <note>
+                        You can change the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>
+                        to not conflict.
+                    </note></para>
+
+                    <para>
+                    Furthermore, the configuration file must be located in the
+                    current build directory in a directory named
+                    <filename>multiconfig</filename> under the build's
+                    <filename>conf</filename> directory where
+                    <filename>local.conf</filename> resides.
+                    The reason for this restriction is because the
+                    <filename>BBPATH</filename> variable is not constructed
+                    until the layers are parsed.
+                    Consequently, using the configuration file as a
+                    pre-configuration file is not possible unless it is
+                    located in the current working directory.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Add the BitBake Multi-Config Variable to you Local Configuration File</emphasis>:
+                    Use the
+                    <filename>BBMULTICONFIG</filename>
+                    variable in your <filename>conf/local.conf</filename>
+                    configuration file to specify each separate configuration.
+                    For example, the following line tells BitBake it should load
+                    <filename>conf/multiconfig/configA.conf</filename>,
+                    <filename>conf/multiconfig/configB.conf</filename>, and
+                    <filename>conf/multiconfig/configC.conf</filename>.
+                    <literallayout class='monospaced'>
+     BBMULTICONFIG = "configA configB configC"
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Launch BitBake</emphasis>:
+                    Use the following BitBake command form to launch the
+                    build:
+                    <literallayout class='monospaced'>
+     $ bitbake [multiconfig:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable> [[[multiconfig:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable>] ... ]
+                    </literallayout>
+                    Following is an example that supports building a minimal
+                    image for configuration A alongside a standard
+                    <filename>core-image-sato</filename>, which takes its
+                    configuration from <filename>local.conf</filename>:
+                    <literallayout class='monospaced'>
+     $ bitbake multiconfig:configA:core-image-minimal core-image-sato
+                    </literallayout>
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            Support for multiple configurations in this current release of
+            the Yocto Project (&DISTRO_NAME; &DISTRO;) has some known issues:
+            <itemizedlist>
+                <listitem><para>
+                    No inter-multi-configuration dependencies exist.
+                    </para></listitem>
+                <listitem><para>
+                    Shared State (sstate) optimizations do not exist.
+                    Consequently, if the build uses the same object twice
+                    in, for example, two different
+                    <filename>TMPDIR</filename> directories, the build
+                    will either load from an existing sstate cache at the
+                    start or build the object twice.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
     <section id="platdev-working-with-libraries">
         <title>Working With Libraries</title>
 

documentation/ref-manual/introduction.xml

@@ -257,12 +257,6 @@
                         <literallayout class='monospaced'>
      $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>SDK Installer Extras:</emphasis>
-                        Packages needed if you are going to be using the
-                        the standard or extensible SDK:
-                        <literallayout class='monospaced'>
-     $ sudo apt-get install autoconf automake libtool libglib2.0-dev libarchive-dev
-                        </literallayout></para></listitem>
                     <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
                         Packages needed if you are going to run
                         <filename>oe-selftest</filename>:
@@ -301,12 +295,6 @@
      $ sudo dnf install make docbook-style-dsssl docbook-style-xsl \
      docbook-dtds docbook-utils fop libxslt dblatex xmlto xsltproc
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>SDK Installer Extras:</emphasis>
-                        Packages needed if you are going to be using the
-                        standard or extensible SDK:
-                        <literallayout class='monospaced'>
-     $ sudo dnf install autoconf automake libtool glib2-devel libarchive-devel
-                        </literallayout></para></listitem>
                     <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
                         Packages needed if you are going to run
                         <filename>oe-selftest</filename>:
@@ -344,12 +332,6 @@
                         <literallayout class='monospaced'>
      $ sudo zypper install make fop xsltproc dblatex xmlto
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>SDK Installer Extras:</emphasis>
-                        Packages needed if you are going to be using the
-                        standard or extensible SDK:
-                        <literallayout class='monospaced'>
-     $ sudo zypper install autoconf automake libtool glib2-devel libarchive-devel
-                        </literallayout></para></listitem>
                     <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
                         Packages needed if you are going to run
                         <filename>oe-selftest</filename>:
@@ -399,12 +381,6 @@
      $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
      docbook-dtds docbook-utils fop libxslt dblatex xmlto xsltproc
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>SDK Installer Extras:</emphasis>
-                        Packages needed if you are going to be using the
-                        standard or extensible SDK:
-                        <literallayout class='monospaced'>
-     $ sudo yum install autoconf automake libtool glib2-devel libarchive-devel
-                        </literallayout></para></listitem>
                     <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
                         Packages needed if you are going to run
                         <filename>oe-selftest</filename>:

documentation/ref-manual/migration.xml

@@ -3392,10 +3392,6 @@
 
         <para>
             The following changes for Python occurred:
-            <note>
-                Python 2 and recipes that use it can still be built for the
-                target as with previous versions.
-            </note>
         </para>
 
         <section id='migration-2.2-bitbake-now-requires-python-3.4'>
@@ -3443,6 +3439,10 @@
                 Unfortunately, systems using RPM as a package manager and
                 providing online package-manager support through SMART still
                 require Python 2.
+                <note>
+                    Python 2 and recipes that use it can still be built for the
+                    target as with previous versions.
+                </note>
             </para>
         </section>
 
@@ -3489,23 +3489,26 @@
         <para>
             <filename>runqemu</filename> has been ported to Python and has
             changed behavior in some cases.
+            Previous usage patterns continued to be supported.
         </para>
 
         <para>
             The new <filename>runqemu</filename> is a Python script.
-            The script requires a configuration file in the following
+            Machine knowledge is no longer hardcoded into
-            form in order to boot the BSP:
+            <filename>runqemu</filename>.
+            You can choose to use the <filename>qemuboot</filename>
+            configuration file to define the BSP's own arguments and to make
+            it bootable with <filename>runqemu</filename>.
+            If you use a configuration file, use the following form:
             <literallayout class='monospaced'>
      <replaceable>image-name</replaceable>-<replaceable>machine</replaceable>.qemuboot.conf
             </literallayout>
-            Machine knowledge is no longer hardcoded into
+            The configuration file enables fine-grained tuning of options
-            <filename>runqemu</filename>.
+            passed to QEMU without the <filename>runqemu</filename> script
-            You can use the <filename>qemuboot</filename> configuration file
+            hard-coding any knowledge about different machines.
-            to define the BSP's own arguments and to make it bootable
+            Using a configuration file is particularly convenient when trying
-            with <filename>runqemu</filename>.
+            to use QEMU with machines other than the
-            <note>
+            <filename>qemu*</filename> machines in OE-Core.
-                Previous usage patterns are continued to be supported.
-            </note>
             The <filename>qemuboot.conf</filename> file is generated by the
             <filename>qemuboot</filename>
             class when the root filesystem is being build (i.e.
@@ -3515,6 +3518,34 @@
             <filename>qemuboot.conf</filename>.
         </para>
 
+
+        <para>
+            If you want to use <filename>runqemu</filename> without a
+            configuration file, use the following command form:
+            <literallayout class='monospaced'>
+     $ runqemu <replaceable>machine</replaceable> <replaceable>rootfs</replaceable> <replaceable>kernel</replaceable> [<replaceable>options</replaceable>]
+            </literallayout>
+            Supported <replaceable>machines</replaceable> are as follows:
+            <literallayout class='monospaced'>
+     qemuarm
+     qemuarm64
+     qemux86
+     qemux86-64
+     qemuppc
+     qemumips
+     qemumips64
+     qemumipsel
+     qemumips64el
+            </literallayout>
+            Consider the following example, which uses the
+            <filename>qemux86-64</filename> machine,
+            provides a root filesystem, provides an image, and uses
+            the <filename>nographic</filename> option:
+            <literallayout class='monospaced'>
+$ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4 tmp/deploy/images/qemux86-64/bzImage nographic
+            </literallayout>
+        </para>
+
         <para>
             Following is a list of variables that can be set in configuration
             files such as <filename>bsp.conf</filename> to enable the BSP
@@ -3579,8 +3610,8 @@
             binary" QA issues when building such recipes.
             You need to fix these recipes so that they use the expected
             <filename>LDFLAGS</filename>.
-            Depending on how the software is built, the build system might
+            Depending on how the software is built, the build system used by
-            need to be patched.
+            the software (e.g. a Makefile) might need to be patched.
             However, sometimes making this fix is as simple as adding the
             following to the recipe:
             <literallayout class='monospaced'>

documentation/ref-manual/ref-variables.xml

@@ -1225,6 +1225,42 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-BBMULTICONFIG'><glossterm>BBMULTICONFIG</glossterm>
+            <info>
+                BBMULTICONFIG[doc] = "Specifies each separate configuration when you are building targets with multiple configurations."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies each separate configuration when you are
+                    building targets with multiple configurations.
+                    Use this variable in your
+                    <filename>conf/local.conf</filename> configuration file.
+                    Specify a <replaceable>multiconfigname</replaceable> for
+                    each configuration file you are using.
+                    For example, the following line specifies three
+                    configuration files:
+                    <literallayout class='monospaced'>
+     BBMULTIFONFIG = "configA configB configC"
+                    </literallayout>
+                    Each configuration file you use must reside in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory's</ulink>
+                    <filename>conf/multiconfig</filename> directory
+                    (e.g.
+                    <replaceable>build_directory</replaceable><filename>/conf/multiconfig/configA.conf</filename>).
+                </para>
+
+                <para>
+                    For information on how to use
+                    <filename>BBMULTICONFIG</filename> in an environment that
+                    supports building targets with multiple configurations,
+                    see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-building-targets-with-multiple-configurations'>Building Targets with Multiple Configurations</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-BBPATH'><glossterm>BBPATH</glossterm>
             <info>
                 BBPATH[doc] = "Used by BitBake to locate .bbclass and configuration files. This variable is analogous to the PATH variable."

documentation/yocto-project-qs/yocto-project-qs.xml

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

meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.1.bbappend

@@ -7,11 +7,11 @@ KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
 KMACHINE_genericx86 ?= "common-pc"
 KMACHINE_genericx86-64 ?= "common-pc-64"
 
-SRCREV_machine_genericx86    ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
+SRCREV_machine_genericx86    ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
-SRCREV_machine_genericx86-64 ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
+SRCREV_machine_genericx86-64 ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
-SRCREV_machine_edgerouter ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
+SRCREV_machine_edgerouter ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
-SRCREV_machine_beaglebone ?= "3e064525c427e128d08ea599ea3247e2963b54a5"
+SRCREV_machine_beaglebone ?= "12532e753b50997690923e03edb3ac3368817a26"
-SRCREV_machine_mpc8315e-rdb ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
+SRCREV_machine_mpc8315e-rdb ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
 COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"

meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend

@@ -7,11 +7,11 @@ KBRANCH_edgerouter = "standard/edgerouter"
 KBRANCH_beaglebone = "standard/beaglebone"
 KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
 
-SRCREV_machine_genericx86    ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
+SRCREV_machine_genericx86    ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
-SRCREV_machine_genericx86-64 ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
+SRCREV_machine_genericx86-64 ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
-SRCREV_machine_edgerouter ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
+SRCREV_machine_edgerouter ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
-SRCREV_machine_beaglebone ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
+SRCREV_machine_beaglebone ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
-SRCREV_machine_mpc8315e-rdb ?= "50e000bc5fce1e04a1a3aea5ffc57c3d5fd71e72"
+SRCREV_machine_mpc8315e-rdb ?= "7fa42ad9a43ca4bb1e578e208ffeddae2d6150e2"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
 COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
@@ -19,8 +19,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
 COMPATIBLE_MACHINE_beaglebone = "beaglebone"
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 
-LINUX_VERSION_genericx86 = "4.4.22"
+LINUX_VERSION_genericx86 = "4.4.26"
-LINUX_VERSION_genericx86-64 = "4.4.22"
+LINUX_VERSION_genericx86-64 = "4.4.26"
-LINUX_VERSION_edgerouter = "4.4.22"
+LINUX_VERSION_edgerouter = "4.4.26"
-LINUX_VERSION_beaglebone = "4.4.22"
+LINUX_VERSION_beaglebone = "4.4.26"
-LINUX_VERSION_mpc8315e-rdb = "4.4.22"
+LINUX_VERSION_mpc8315e-rdb = "4.4.26"

meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.8.bbappend

@@ -7,11 +7,11 @@ KBRANCH_edgerouter = "standard/edgerouter"
 KBRANCH_beaglebone = "standard/beaglebone"
 KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
 
-SRCREV_machine_genericx86    ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
+SRCREV_machine_genericx86    ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_machine_genericx86-64 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
+SRCREV_machine_genericx86-64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_machine_edgerouter ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
+SRCREV_machine_edgerouter ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_machine_beaglebone ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
+SRCREV_machine_beaglebone ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_machine_mpc8315e-rdb ?= "4c9e17100b1f8ce45a60ad8984c12b00febbc685"
+SRCREV_machine_mpc8315e-rdb ?= "4be88b03f6648004e74b68044fa2b05e81cf9a1b"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
 COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
@@ -19,8 +19,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
 COMPATIBLE_MACHINE_beaglebone = "beaglebone"
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 
-LINUX_VERSION_genericx86 = "4.8"
+LINUX_VERSION_genericx86 = "4.8.3"
-LINUX_VERSION_genericx86-64 = "4.8"
+LINUX_VERSION_genericx86-64 = "4.8.3"
-LINUX_VERSION_edgerouter = "4.8"
+LINUX_VERSION_edgerouter = "4.8.3"
-LINUX_VERSION_beaglebone = "4.8"
+LINUX_VERSION_beaglebone = "4.8.3"
-LINUX_VERSION_mpc8315e-rdb = "4.8"
+LINUX_VERSION_mpc8315e-rdb = "4.8.3"

meta/classes/image_types.bbclass

@@ -184,7 +184,7 @@ IMAGE_CMD_ubi () {
 
 IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.ubifs ${MKUBIFS_ARGS}"
 
-WKS_FILE ?= "${IMAGE_BASENAME}.${MACHINE}.wks"
+WKS_FILE ??= "${IMAGE_BASENAME}.${MACHINE}.wks"
 WKS_FILES ?= "${WKS_FILE} ${IMAGE_BASENAME}.wks"
 WKS_SEARCH_PATH ?= "${THISDIR}:${@':'.join('%s/scripts/lib/wic/canned-wks' % l for l in '${BBPATH}:${COREBASE}'.split(':'))}"
 WKS_FULL_PATH = "${@wks_search('${WKS_FILES}'.split(), '${WKS_SEARCH_PATH}') or ''}"

meta/recipes-core/images/build-appliance-image_15.0.0.bb

@@ -22,8 +22,8 @@ IMAGE_FSTYPES = "vmdk"
 
 inherit core-image module-base
 
-SRCREV ?= "4b94b498e21aeba945fe7e72a6b7c4bb0314fb83"
+SRCREV ?= "746c681be4c744d0c6c2d3225b94550241546f65"
-SRC_URI = "git://git.yoctoproject.org/poky;branch=master \
+SRC_URI = "git://git.yoctoproject.org/poky;branch=morty \
            file://Yocto_Build_Appliance.vmx \
            file://Yocto_Build_Appliance.vmxf \
            file://README_VirtualBox_Guest_Additions.txt \

meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb

@@ -11,8 +11,8 @@ python () {
         raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "320bceb35315d118c1e209effd441eb8a8dbad57"
+SRCREV_machine ?= "4057556c041f6aac0d29aa3425587d414c9a0090"
-SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
+SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.8.git;branch=${KBRANCH};name=machine \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"

meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb

@@ -10,7 +10,7 @@ KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
+SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 

meta/recipes-kernel/linux/linux-yocto_4.8.bb

@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
 SRCREV_machine_qemux86-64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
 SRCREV_machine_qemumips64 ?= "64f96ba530e58456070f26b0f3fcce3f64988b72"
 SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
+SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.8.git;name=machine;branch=${KBRANCH}; \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"

scripts/lib/devtool/runqemu.py

@@ -48,7 +48,12 @@ def runqemu(args, config, basepath, workspace):
         raise DevtoolError('Unable to determine image name to run, please specify one')
 
     try:
-        exec_build_env_command(config.init_path, basepath, 'runqemu %s %s %s' % (machine, imagename, " ".join(args.args)), watch=True)
+        # FIXME runqemu assumes that if OECORE_NATIVE_SYSROOT is set then it shouldn't
+        # run bitbake to find out the values of various environment variables, which
+        # isn't the case for the extensible SDK. Work around it for now.
+        newenv = dict(os.environ)
+        newenv.pop('OECORE_NATIVE_SYSROOT', '')
+        exec_build_env_command(config.init_path, basepath, 'runqemu %s %s %s' % (machine, imagename, " ".join(args.args)), watch=True, env=newenv)
     except bb.process.ExecutionError as e:
         # We've already seen the output since watch=True, so just ensure we return something to the user
         return e.exitcode