To B0[+] chips, dcd_skip needs to be true. For A0 chip, it needs
to be false, however A0 chip is no longer being supported anymore.
Considering we are moving code from imx-mkimage to uboot mkimage,
to make sure we not introduce some surprise, we still keep dcd_skip
code there.

Signed-off-by: Peng Fan <peng.fan@nxp.com>

imx for 2019.01

- introduce support for i.MX8M
- fix size limit for Vhybrid / pico boards
- several board fixes
- w1 driver for MX2x / MX5x

Build flash.bin for i.MX8MQ, it will include signed hdmi firmware,
spl, ddr firmware, fit image(bl31.bin, u-boot-nodtb.bin, dtb).
Burn it to 33KB offset of SD card.

Signed-off-by: Peng Fan <peng.fan@nxp.com>

i.MX8M bootable image type is like i.MX6/7, but there is signed HDMI
firmware image in front of A53 bootable image, which is also has an IVT
header.

Here we also include fit image to generate a bootable image.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Stefano Babic <sbabic@denx.de>

Replace non-portable operator == with =

The operator == in sh(1) / test(1) is non-POSIX and only implemented by
some shells (like bash). It is equivalent to the standard defined operator =.

Starting from version 8 the GCC, i.e. C compiler, starts complaining about
possible '\0' terminator loss or, as in this case, garbage copy.

In function ‘mtk_image_set_gen_header’,
    inlined from ‘mtk_image_set_header’ at tools/mtk_image.c:733:3:
tools/mtk_image.c:659:2: warning: ‘strncpy’ specified bound 12 equals destination size [-Wstringop-truncation]
  strncpy(hdr->boot.name, bootname, sizeof(hdr->boot.name));
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘mtk_brom_parse_imagename’,
    inlined from ‘mtk_image_check_params’ at tools/mtk_image.c:388:9:
tools/mtk_image.c:325:5: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation]
     strncpy(lk_name, val, sizeof(lk_name));
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Replace it with snprintf() to tell compiler how much room we have in the
destination buffer for source string.

Fixes: 3b975a147c3c ("tools: MediaTek: add MTK boot header generation to mkimage")
Cc: Ryder Lee <ryder.lee@mediatek.com>
Cc: Weijie Gao <weijie.gao@mediatek.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Weijie Gao <weijie.gao@mediatek.com>

The motivation for this is to allow distributions to distribute all
possible tools in a generic way, avoiding the need of specific tools
building for each machine.

Especially on OpenEmbedded / Yocto Project ecosystem, it is very
common each BSP to end providing their specific tools when they need
to generate images for some SoC (e.g MX23 / MX28 in meta-freescale
case).

Using this, we can package the tools doing:

$: make tools-only_defconfig
$: make tools-only

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
[trini: Add MAINTAINERS entry for myself, add to .travis.yml, make
U-Boot itself buildable to not trip up other frameworks]
Signed-off-by: Tom Rini <trini@konsulko.com>

The CRC16-CCITT checksum function is useful for space-constrained
applications (such as obtaining a checksum across a 2KBit or 4KBit
EEPROM) in boot applications. It has not been accessible from boot
scripts until now (due to not having a dedicated command and not being
supported by the hash infrstructure) limiting its applicability
outside of custom commands.

This adds the CRC16-CCITT (poly 0x1021, init 0x0) algorithm to the
list of available hashes and adds a new crc16_ccitt_wd_buf() to make
this possible.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
[trini: Fix building crc16.o for SPL/TPL]
Signed-off-by: Tom Rini <trini@konsulko.com>

Unfortunately, for some releases the kernel.org toolchain tarball names adhere
to the following pattern:

	<hostarch>-gcc-<ver>-nolib-<targetarch>-<type>.tar.xz

e.g.:
	x86_64-gcc-8.1.0-nolibc-aarch64-linux.tar.xz

while others use the following pattern:

	<hostarch>-gcc-<ver>-nolib_<targetarch>-<type>.tar.xz

e.g.:

	x86_64-gcc-7.3.0-nolibc_aarch64-linux.tar.xz

Notice that the first pattern has dashes throughout, while the second has
dashes throughout except just before the target architecture which has an
underscore.

The "dash throughout" versions from kernel.org are:

	8.1.0, 6.4.0, 5.5.0, 4.9.4, 4.8.5, 4.6.1

while the "dash and underscore" versions from kernel.org are:

	7.3.0, 4.9.0, 4.8.0, 4.7.3, 4.6.3, 4.6.2, 4.5.1, 4.2.4

This tweak allows the code to handle both versions. Note that this tweak also
causes the architecture parsing to get confused and find the following two
bogus architectures, "2.0" and "64", which are explicitly checked for, and
removed.

Signed-off-by: Trevor Woerner <trevor@toganlabs.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Change single quotes to double quotes:
Signed-off-by: Simon Glass <sjg@chromium.org>

The hexagon toolchain (4.6.1) from kernel.org, for example, was packaged in
a way that is different from most toolchains. The first entry when unpacking
most toolchain tarballs is:

	gcc-<version>-nolib/<targetarch>-<system>

e.g.:

	gcc-8.1.0-nolibc/aarch64-linux/

The first entry of the hexagon toolchain, however, is:

	gcc-4.6.1-nolibc/

This causes the buildman logic in toolchain.py::ScanPath() to not be able to
find the "*gcc" executable since it looks in gcc-4.6.1-nolib/{.|bin|usr/bin}
instead of gcc-4.6.1/hexagon-linux/{.|bin|usr/bin}. Therefore when buildman
tries to download a set of toolchains that includes hexagon, the script fails.

This update takes the second line of the tarball unpacking (which works for
all the toolchains I've tested from kernel.org) and parses it to take the
first two elements, separated by '/'. It makes this logic a bit more robust.

Signed-off-by: Trevor Woerner <trevor@toganlabs.com>
Reviewed-by: Simon Glass <sjg@chromium.org>