linux-yocto/3.10: update to v3.10.54 and -rt55

The 3.10 kernel needed a refresh to the latest -stable and -rt releases.

(From OE-Core rev: c7360e9e72f06dab2617e16ae546f4d8e5262fa1)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
linux-yocto/3.14: update to v3.14.18 and -rt9

Refreshing the 3.14 kernel to a new korg stable and -rt release.

(From OE-Core rev: 91204afeb508ae21f8f2a32c340ec85efbf33fd0)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
linux-yocto/3.17: update to v3.17-rc5

Bumping the SRCREVs to import the latest korg -rc.

(From OE-Core rev: 8ae153f7da3244c3dd24cc5dbd722af26624201b)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
linux-yocto/3.17: switch to dedicated 3.17 repository

The 3.17 repository is ready, so we no longer need to reuse the
linux-yocto-dev tree.

(From OE-Core rev: c304674833360e0e2dceca3ebeb535025597e46f)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
linux-yocto/3.17: bump to v3.17-rc6

Updating the 3.17 recipe to -rc6. This is nearly the release kernel, and should
have very few changes aftert this point.

(From OE-Core rev: 845e01d906982c2147828b97129e95e8a79dce7c)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
linux-yocto/3.10: update to v3.10.55

Updating to the latest korg -stable update.

(From OE-Core rev: 9745ffc0ae25be980d92f195937cef6d1f406ab2)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
linux-yocto/3.14: update to v3.14.19

Updating to the latest korg -stable update.

(From OE-Core rev: 7212dcb3a67b9a9b844b74e997d2e3ea7902555f)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oe-init-build-env-memres: Fix automatic port usage

The use of an automatic port wasn't working correctly since the server
was never getting started when port == -1. This fixes things so the
server is started when port is not specified (i.e. automatic) ensuring
this happens before BBSERVER is set.

[YOCTO #6563]

(From OE-Core rev: 982553b6d56ca4bfd095c1bcb736ae3b77deefa7)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
irda-utils: remove inherit autotools

irda-utils doesn't use autotools, so don't inherit it.

(From OE-Core rev: d5e2a59ab59e3d67d09c5f25b8623186af855e17)

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake: knotty: Ensure commandline parameters are updated in memres server

When using options like -k, -f, -v and so on with the memory resident
server, they'd currently only be set on the initial values passed to
the original command. This ensures they now match those specified
on the commandline for the options where this makes sense.

To make this work, a command to update the options on the server side
is required so this is added.

[YOCTO #5292]

(Bitbake rev: 1c75cc4d0c8b606c1fe76e6bf60bf6a32298b105)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake: fetch2/perforce: Fix localfile name if labels are used

I could apply the label "release_1.0" to a super project that contains
many sub projects.  If my recipes have SRC_URI's that use that label but
grab different sub-folders, than there's a bug where the cached localfile
(tar.gz) will not be unique and reused at the wrong times.

SRC_URI = "p4://perforce::1234@//depot/SuperProject/MiniProjectAAA/...;label=release_1.0 \
                     p4://perforce::1234@//depot/SuperProject/MiniProjectBBB/...;label=release_1.0"

(Bitbake rev: 3b5b1703b77490116dda895b29737cea51a3d6a0)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake: fetch2/perforce: Use replace (1 line) instead of find (3 lines)

(Bitbake rev: 5bf5a937b26896bedbfea78dd1d62bce5a26ac2a)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
uninative: Add uninative - a way of reusing native/cross over multiple distros

These patches are the start of a new idea, a way of allowing a single set of
cross/native sstate to work over mutliple distros, even old ones.

The assumption is that our own C library is basically up to date. We build
and share a small tarball (~2MB) of a prebuilt copy of this along with a
patchelf binary (which sadly is C++ based so libstdc++ is in there). This
tarball can be generated from our usual SDK generation process through
the supplied recipe, uninative-tarball.

At the start of the build, if its not been extracted into the sysroot, this
tarball is extracted there and configured for the specified path.

When we install binaries from a "uninative" sstate feed, we change the
dynamic loader to point at this dynamic loader and C librbary. This works
exactly the same way as our relocatable SDK does. The only real difference
is a switch to use patchelf, so even if the interpreter section is too small,
it can still adjust the binary.

Right now this implements a working proof of concept. If you build the tarball
and place it at the head of the tree (in COREBASE), you can run a build from
sstate and successfully build packages and construct images.

There is some improvement needed, its hardcoded for x86_64 right now, its trivial
to add 32 bit support too. The tarball isn't fetched right now, there is just a
harcoded path assumption and there is no error handling. I haven't figured
out the best delivery mechanism for that yet. BuildStarted is probably not
the right event to hook on either.

I've merged this to illustrate how with a small change, we might make the
native/cross sstate much more reusable and hence improve the accessibility
of lower overhead builds. With this change, its possible the Yocto Project may
be able to support a configured sstate mirror out the box. This also has
positive implications for our developer workflow/SDK improvements.

(From OE-Core rev: e66c96ae9c7ba21ebd04a4807390f0031238a85a)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic: minor comment update

Update comment about types of generated partition images.

(From OE-Core rev: ba1503f77e0c03fe6c715b61983008b7a534ae20)

Signed-off-by: Maciej Borzecki <maciej.borzecki@open-rnd.pl>
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic: use IMAGE_EXTRA_SPACE for vfat rootfs

Functions for generating rootfs use IMAGE_EXTRA_SPACE rather than
BOOTDD_EXTRA_SPACE. The latter is used in boot image source plugins.

(From OE-Core rev: 44abf447f8e4ed11cbbe53a4fb0ecf10a20f0f9e)

Signed-off-by: Maciej Borzecki <maciej.borzecki@open-rnd.pl>
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic: fix vfat partition sector count only if needed

VFAT rootfs partitions sector count would get updated always even if
there is no need. Since parition size in wic is expressed in MB, any
sub MB change will cause the generated partition image to be larger
than allocated space within the disk image. Fortunately, partitions
sized in MB will most of the time have a proper sector count.

(From OE-Core rev: 99bee4cb489800d74dea4d2158ff834413685f04)

Signed-off-by: Maciej Borzecki <maciej.borzecki@open-rnd.pl>
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic: set bootimg_dir when using image-name artifacts

Running wic with -e to use artifacts from a named image, bootimg_dir was
always passed as empty string to partition source plugins. The patch
sets bootimg_dir to current value of DEPLOY_DIR_IMAGE, as bootloader
artifacts end up in that location as well.

(From OE-Core rev: d7f69e6f0932a927b6ce289fb47ba575d7aaa1c8)

Signed-off-by: Maciej Borzecki <maciej.borzecki@open-rnd.pl>
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
documentation.conf: document IMAGE_BOOT_FILES

Document IMAGE_BOOT_FILES variable.

(From OE-Core rev: 8007f41aa824db2ee681d9dd98a0b06f44fc9d6d)

Signed-off-by: Maciej Borzecki <maciej.borzecki@open-rnd.pl>
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic: add new bootimg-partition plugin

This patch implements 'bootimg-partition source plugin class for 'wic'. The
plugin creates an image of boot partition, copying over files listed in
IMAGE_BOOT_FILES bitbake variable.

(From OE-Core rev: 4a3200d710d953956064c28188577fbd461d093d)

Signed-off-by: Maciej Borzecki <maciej.borzecki@open-rnd.pl>
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic: add sdimage-bootpart kickstart file

Add kickstart for generating a SD card image that should cover most use
case scenarios. The layout is as follows:
- 16MB vfat partition that IMAGE_BOOT_FILES will be copied to, 4k
  alignment
- ext4 rootfs, 4k alignment

(From OE-Core rev: bb01a6be7b32aa675f5003a6012a60a081212e8c)

Signed-off-by: Maciej Borzecki <maciej.borzecki@open-rnd.pl>
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>