Merge branch 'for-next/socfpga'

ARM: socfpga: Arria10: support programming FPGA in PBL ...

Some Arria10 boards don't have the FPGA programmed externally.
Instead barebox needs to do that. As the Arria10 has the SDRAM
controller in the FPGA, the first thing we need to do is,
configure the FPGA before the SDRAM can even be used.

It works like this:
  1. boot ROM fetches the PBL from MMC
  2. read the MBR from MMC (this depends on the setup done by the boot ROM)
  3. read the Bitstream from the MMC and program the FPGA
  4. re-read the barebox image from MMC, this time with the full barebox
     that is appended to the PBL
  5. jump into the full barebox

Only supported boot device is eMMC.

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

ARM: Add code to support SMCCC on AArch64 ...

Port SMCCC code from Linux kernel. To accomodate that:

  - Introduce CONFIG_ARM_SMCCC, to allow enabling the code
    independent of CONFIG_ARM_SECURE_MONITOR

  - Bring <linux/arm-smccc.h> in

  - Add necessary constants to arch/arm/asm-offsets.c

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Merge branch 'for-next/misc'

scripts: create a separate section for host tools ...

This allows to enable host tools even if they are not needed for the
current configuration to improve compile coverage and simplify packaging
these tools. The conversion doesn't cover all tools available but can be
extended later.

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

ARM: lib64: Make string functions aware of MMU configuration ...

Optimized version of memset() in memset.S if called as:

    memset(foo, 0, size)

will try to explicitly zero out data cache with:

    dc	zva, dst

which will result in Alignement Exception (DABT) if MMU is not
enabled.

For more info see:

    - C4.4.8 "DC ZVA, Data Cache Zero by VA"
    - D5.2.8 "The effects of disabling a stage of address translation"

in "ARM Architecture Reference Manual. ARMv8, for ARMv8-A architecture
profile"

In similar vein, using optimized version of memcpy() could lead to a
unaligned 16-byte write (using 'stp'), which is not allowed for
Device-nGnRnE type of memory (see D5.2.8) and would liead to
Alignement Exception.

To fix both problems expose non-optimized and optimzied versions of
the function and created a wrapper to dispatch the call to either one
based on if MMU is enabled or not.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Add builtin firmware support ...

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
[andrew.smirnov@gmail.com: Add dummy.o in case directory is empty]
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: aarch64: hide some config options ...

EABI and ATAGS have no meaning on aarch64, so hide the options from the
user.

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

ARM: For relocatable image force TEXT_BASE 0x0 ...

Nothing else should be used for the relocatable image case, so
force TEXT_BASE to 0x0 and do not show it in the menu.

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

ARM: socfpga: add arria10 support ...

Arria10 is a SoC + FPGA like the Cyclone5 SoCFPGA that
is already supported in barebox.
Both a the same in some parts, but totaly different in
others. Most of the hardware blocks are the same in the
SoC parts. The OCRAM is larger on the Arria10 and the
SDRAM controller is different.
The serial core only supports 32bit accesses (different to
the 8bit accesses on the Cyclone5).

As Arria10 has 256KB of OCRAM, it is possible to fit a larger
barebox (and/or use PBL) instead of the two stage bootprocess
used on the Cyclone5 and its 64KB OCRAM.

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

Merge branch 'for-next/misc'

ARM: mvebu: remove obsolete select ...

This is a user choice now and has been removed for all other boards in commit
790980bf18af ("Make generic default environment type a use choice").

Signed-off-by: Ulrich Ölmann <u.oelmann@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

poweroff: Allow to register poweroff handlers ...

Allow to register handlers for poweroff. This allows to have multiple
poweroff implementations in a single binary. The implementation is close
to the restart handlers.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

at91sam9x5ek: Convert to mult-image build ...

Convert AT91SAM9X5-EK board code to multi-image build process, similar
to how majority of i.MX board code is built.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

clk: at91: Port at91 DT clock code ...

Port at91 DT clock code from Linux 4.9-rc3.

Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Merge branch 'for-next/rpi'

Merge branch 'for-next/mvebu'

scripts: imx/mxs remove mxs-usb-loader ...

... and use imx-usb-loader instead

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

mvebu: get initial position of register window from image header ...

A problem when using 2nd stage booting on mvebu is that the first bootloader
already switched the register window location from 0xd0000000 to
0xf1000000 by writing to 0xd0000080. When the second bootloader also
tries to do this switch it writes to the wrong location resulting in an
exception and so a boot failure.

For this reason the base address of the register window is passed in the
barebox header and picked up from there by early code. In a further
patch bootm is taught to put the actual position of the window there for
the second bootloader to finally make second stage booting work.

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

ARM: rpi: switch to DT probe and multi-image build ...

This commit switches the RaspberryPi arch over to probe Barebox
from the builtin DT and enables multi-image builds.

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

ARM: rpi: always build relocatable image ...

Makes more space available for the malloc area and will allow
to switch to multi-image later on.

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

ARM: Add PSCI support ...

This patch contains the barebox implementation for the ARM
"Power State Coordination Interface" (PSCI).

The interface is aimed at the generalization of code in the following
power management scenarios:
* Core idle management.
* Dynamic addition and removal of cores, and secondary core boot.
* big.LITTLE migration.
* System shutdown and reset.

In practice, all that's currently implemented is a way to enable the
secondary core one some SoCs.

With PSCI the Kernel is either started in nonsecure or in Hypervisor
mode and PSCI is used to apply power to the secondary cores.

The start mode is passed in the global.bootm.secure_state variable. This
enum can contain "secure" (Kernel is started in secure mode, means no
PSCI), "nonsecure" (Kernel is started in nonsecure mode, PSCI available)
or "hyp" (Kernel is started in hyp mode, meaning it can support
virtualization).

We currently only support putting the secure monitor code into SDRAM,
which means we always steal some amount of memory from the Kernel.
To keep things simple for now we simply keep the whole barebox binary in
memory

The PSCI support has been tested on i.MX7 only so far. The only
supported operations are CPU_ON and CPU_OFF.

The PSCI and secure monitor code is based on the corresponding U-Boot
code.

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

arm64: disable PBL support ...

PBL is another feature, which needs some love to work on ARM64.

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

Merge branch 'for-next/mvebu'

Merge branch 'for-next/defenv'

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>

arm: semihosting support is not implemented for ARM64 ...

Don't allow it to be selected in a ARM64 build.

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

arm(64): move HAS_DMA and HAS_MODULES to CPU_32 ...

We don't yet have an implementation for those two features on ARM64, so move
them to a place where they are only selected for a 32bit barebox.

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

ARM: mvebu: select HAVE_DEFAULT_ENVIRONMENT_NEW ...

None of the available boards for mvebu has any environment additions, so
this is safe.

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

Merge branch 'for-next/imx'