ARM: imx6: add support for Auvidea H100 ...

The Auvidea H100 is a baseboard for the SolidRun MicroSOM, which
provides HDMI IN/OUT capabilities.

Currently supported is only a combination of the H100 baseboard
with a i2eX MicroSOM.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: microsom: use imx6q_barebox_entry ...

Instead of hardcoding the different RAM sizes.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Merge branch 'for-next/usb'

Merge branch 'for-next/ubi'

Merge branch 'for-next/state'

Merge branch 'for-next/mvebu'

Merge branch 'for-next/mtd'

Merge branch 'for-next/misc'

Merge branch 'for-next/imx'

Merge branch 'for-next/dts'

Merge branch 'for-next/defenv'

Merge branch 'for-next/bootchooser'

Merge branch 'for-next/arm'

Make generic default environment type a use choice ...

So far it was hardcoded for each board if defenv-1 or defenv-2 is used.
Make this a user choice so that a particular board no longer enforces
a defenv type.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

defaultenv: add defaultenv-1 in boards via defaultenv_append_directory() ...

Currently it's hardcoded for each board which defaultenv version is
used. This is unfortunate since some people like the other defaultenv
version better and may want to select it.

This patch removes the board specific environment path
CONFIG_DEFAULT_ENVIRONMENT_PATH and instead adds it via:

	if (IS_ENABLED(CONFIG_DEFAULT_ENVIRONMENT_GENERIC))
		defaultenv_append_directory(defaultenv_<board>);

This way we can make sure that the defaultenv-1 board specific bits are
only compiled in when defaultenv-1 is actually in use.

The next step is to make the defaultenv version selection a user visible
choice.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Release v2016.10.0 ...

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: mvebu: document some general mvebu stuff and the rn2120 board ...

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: mvebu: add support for Netgear RN2120 ...

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Add support for Baltos systems ...

OnRISC Baltos devices are based on a am335x SoC and can be booted
either from MMC or NAND.

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

completion: Fix completion for devices with a dot in the name ...

Devices can have a dot in the name, so do not expect the full
device name before the first dot.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Allow device parameters for devices with dots in name ...

Devices can have a dot in the name, so we can't expect to find the
full device name before the first dot. Currently parameters of devices
with a dot in the name are inaccessible from the shell.
Fix this by iterating over the possible device name / parameter name
combinations to find a existing combination.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

pinctrl: mvebu: armada-370 fix gpio name for mpp63 ...

It was found that pin 63 also works as input and so the respective function
is renamed from "gpo" to "gpio". The respective commit in Linux is:

	a526973e0291 ("pinctrl: mvebu: Fix mapping of pin 63 (gpo -> gpio)")

which appeared in v4.1-rc3. The devicetrees are fixed accordingly since
commit

	ce5cad51f381 ("ARM: dts: armada-370: Update the mpp63 function in the device tree on Armada 370")

which appeared in v4.6-rc1.

This fixes a runtime warning on the affected machines
(globalscale-mirabox and netgear-rn104) and makes the pin functional
again.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

pinctrl: mvebu: add newline to error message ...

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

images: mvebu: don't generate uart images ...

kwboot knows how to work with an image for a different boot medium now.
So there is no reason to generate a dedicated UART image any more.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

scripts: kwboot: set boot source to UART before sending ...

Sending an image that specifies one of the alternative boot sources doesn't
make sense. So change the boot source to UART on the fly.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

scripts: kwboot: simplify kwboot_mmap_image ...

There was only a single caller who passes prot=PROT_READ unconditionally.
So drop this parameter and simplify accordingly.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

scripts: kwboot: shorten delay between two boot messages ...

Together with the previous changes that allow to handle the scenario where
too many messages were sent, this greatly improves the probability to hit
the time window during which the CPU accepts a boot message.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

scripts: kwboot: improve diagnostic output ...

After entering uart boot mode the CPU prints some diagnostic messages.
Showing them to the user helps her to notice when the message window was
missed or there is an other problem.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

scripts: kwboot: flush input and output only once ...

When flushing input before sending of a boot message the acknowledging
reply for the previous message from the CPU might be discarded and so
missed.

So only flush once before sending boot messages in a loop.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

scripts: kwboot: try to resync on packet boundary after receiving a NAK ...

If we sent the boot message too often the CPU might already have started
to interpret this as an xmodem packet. As sender and receiver are not in
sync it's impossible to transfer a packet successfully.

So when we get a NAK send '\xff' bytes until the receiver reaches the
packet boundary. When we send too many the SoC replies with a NAK for
each byte and doesn't interpret it as the start of a new package (which
must start with SOH == '\x01').

A slower alternative would be to wait for another NAK which is sent when
reception of the already started packet times out.

This was tested on an Armada XP based machine with bootrom version 1.20.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>