wic: Don't allow mkfs to fail silently in partition command

The return code from the mkfs command used by the partition creation
command was being ignored, allowing it to silently fail and leaving
users mystified as to why the resulting filesystem was corrupted.

This became obvious when failures occurred when creating large
e.g. sdk filesystems [YOCTO #6863].

(From OE-Core rev: 8cef3b06f7e9f9d922673f430ddb3170d2fac000)

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic: Use overhead factor when creating partitions from rootfs directories

When creating partitions sized to given rootfs directories, filesystem
creation could fail in cases where the calculated target partition
size was too small to contain the filesystem created using mkfs.  This
occurred in particular when creating partitions to contain very large
filesystems such as those containing sdk image artifacts.

This same limition is present in the oe-core image creation classes,
which can be readily see by changing IMAGE_OVERHEAD_FACTOR from the
default 1.3 to 1.0 and building a sato-sdk image.

It should be possible to calculate required sizes exactly given the
source rootfs and target filesystem types, but for now, to address the
specific problem users are hitting in such situations, we'll just do
exactly what oe-core does and define and use an IMAGE_OVERHEAD_FACTOR
or 1.3 in those cases.

Fixes [YOCTO #6863].

(From OE-Core rev: bbaef3ff5833fc1d97b7b028d7770834f62789da)

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic: Update the help text to include -D (--debug)

The --debug option is missing from the wic help text; this adds it and
at the same time rearranges the usage into a more logical arrangement.

(From OE-Core rev: cf5144ef241d8f4ccaa3461ae5c9f89c2cf2f8d1)

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Revert "wic: set bootimg_dir when using image-name artifacts"

This reverts commit 7ce1dc13f91df70e8a2f420e7c3eba51cbc4bd48.

This patch broke the assumption that a non-null boot_dir means a
user-assigned (-b command-line param) value.

Reverting doesn't break anything, since the case it was added for
doesn't use the boot_dir for anything except debugging anyhow.

Fixes [YOCTO #6290]

(From OE-Core rev: db90f10bf31dec8d7d7bb2d3680d50e133662850)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic: Remove special-case bootimg_dir

The first iterations of wic very shortsightedly catered to two
specific use-cases and added special-purpose params for those cases so
that they could be directly given their corresponding boot artifacts.
(hdddir and staging_data_dir).

As more use-cases are added, it becomes rather obvious that such a
scheme doens't scale, and additionally causes confusion for plugin
writers.

This removes those special cases and states explicitly in the help
text that plugins are responsible for locating their own boot
artifacts.

(From OE-Core rev: 6ba3eb5ff7c47aee6b3419fb3a348a634fe74ac9)

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic: Update bootimg-partition to use bootimg_dir

Update bootimg-partition to use bootimg_dir instead of img_deploy_dir,
to match similar usage in other plugins.

As mentioned elsewhere, plugins should use the passed-in value for
bootimg_dir directly if non-null, which corresponds to a user-assigned
value specified via a -b command-line param, and only fetch the value
from bitbake if that value is null.

(From OE-Core rev: 3822f8a7b33da56ecd9144b4bcae50734fb1af81)

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic: Update bootimg-micro-galileo plugin

Conform to new wic model e.g. mic gone, move from mic to wic, exec_cmd
changed so rc, out no longer works, new param lists and so on.

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>