Merge branch 'for-next/arm'

Release v2019.05.0 ...

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

ARM: aarch64: do not use 32bit optimized find bit functions ...

The optimized find bit functions are only implemented for 32 bit and are
not built on aarch64 systems. Therefore, for example bootchooser cannot
be build for aarch64.

Select the generic find_bit implementations on aarch64.

As the decision, if lib64 or lib32 is build or not, directly depends on
CPU_V8, the generic implementation also should be used if CPU_V8 is
selected.

Reported-by: Thomas Hämmerle <Thomas.Haemmerle@wolfvision.net>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: zii-imx8mq-dev: select ZII_COMMON ...

The RDU3 shares some of the board fixups with the other Zii boards.
For those to work ZII_COMMON needs to be enabled.

Fixes: d76ba38a1605 (ARM: zii-common: reuse i210 config check for RDU3)
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: imx: disable IPU QoS setup for correct SoCs ...

The condition was introduced in 4e6e8f73e9 ("ARM: imx6: don't
execute IPU QoS setup on MX6 SX/SL"), but instead it bails at
the Solo, not the SX and SL.

The original intent was most probably to add an exception for
the i.MX6 Solo as well, so everything else is skipped, including
the SX, SL and now the UL and ULL. Fix the code to reflect this.

On the SX, SL, UL, ULL, this now avoids writes to memory, which
isn't described in the datasheets. On the S, it now configures
the QoS settings.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: mmu: mark uncached regions as eXecute never on v7 ...

The ARM Cortex-A Series Programmer's Guide notes[1]:
> When set, the Execute Never (XN) bit in the translation table entry
> prevents speculative instruction fetches taking place from desired
> memory locations and will cause a prefetch abort to occur if execution
> from the memory location is attempted.
>
> Typically device memory regions are marked as execute never to prevent
> accidental execution from such locations, and to prevent undesirable
> side-effects which might be caused by speculative instruction fetches.

Heed the advice and mark uncached memory with the XN bit, when the
CPU is >=v7.

It's possible that there are SoCs that have a section shared between
device memory and the on-chip RAM hosting the PBL.
In such a section, every page except for the OCRAM's should be mapped XN,
but as we know of no SoC with such an OCRAM layout, we ignore this
possibility for now and let mmu_early_enable map sections only.

[1]: 9.6.3 "Execute Never", Version 4.0

Suggested-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: mmu: remove doubly defined macro ...

PMD_SECT_DEF_CACHED is defined along with PMD_SECT_DEF_UNCACHED
in mmu.h, which is included two lines prior.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: cache-armv7: start invalidation from outer levels ...

On 25/4/19 11:57, Lucas Stach wrote:
> [T]he sequence that could go wrong in Barebox is as follows:
> 1. CPU core starts invalidating at L1 cache level
> 2. HW prefetcher decides that a specific address should be brought into
> the L1 cache.
> 3. HW prefetcher finds a valid block for the requested address in L2
> cache and moves cached data from L2 to L1.
> 4. Only now CPU core invalidates L2 cache.
>
> In the above sequence we now have invalid data in the L1 cache line.
> The correct sequence will avoid this issue:
>
> 1. CPU core starts invalidating at L2 cache level
> 2. HW prefetcher decides that a specific address should be brought into
> the L1 cache.
> 3. HW prefetcher sees invalid tags for the requested address in L2
> cache and brings in the data from external memory.
> 4. CPU core invalidates L1 cache, discarding the prefetched data.
>

The ARM Cortex-A Series Programmer's Guide addresses this issue
in the SMP-context[1]:
> If another core were to access the affected address between those
> two actions, a coherency problem can occur. Such problems can be avoided
> by following two simple rules.
>
> * When cleaning, always clean the innermost (L1) cache first and then
>   clean the outer cache(s).
> * When invalidating, always invalidate the outermost cache first and
>   the L1 cache last.

The current code correctly iterates from inner to outer cache levels
when flushing/cleaning (r8 == 0), invalidation (r8 == 1) occurs in the
same direction though. Adjust the invalidation iteration order to start
from the outermost cache instead.

Equivalent C-Code:

	enum cache_op { CACHE_FLUSH = 0, CACHE_INVAL = 1 };
	register enum cache_op operation asm("r8");
	register int i asm("r12");
	register int limit asm("r3") = max_cache_level << 1; // e.g. 4 with L2 max

	+if (operation == CACHE_FLUSH) {
	 	i = 0;
	+} else {
	+	i = limit - 2;
	+}

	 bool loop_again;
	 do {
		/* [snip] */
	+	if (operation == CACHE_FLUSH) {
			i += 2;
			loop_again = limit > i;
	+	} else {
	+		loop_again = i > 0;
	+		i -= 2;
	+	}
	} while (loop_again);

[1]: 18.6 "TLB and cache maintenance broadcast", Version 4.0

Suggested-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: cache-armv7: work around Cortex-A7 erratum 814220 ...

This patch is based on 0e9a87bb from the linux-imx kernel:
------------------------------------------------------------------------------
| ARM/MP: 814220—B-Cache maintenance by set/way operations can execute
| 	out of order.
|
| Description:
| The v7 ARM states that all cache and branch predictor maintenance operations
| that do not specify an address execute, relative to each other, in program
| order. However, because of this erratum, an L2 set/way cache maintenance
| operation can overtake an L1 set/way cache maintenance operation, this would
| cause the data corruption.
|
| This ERRATA affected the Cortex-A7 and present in r0p2, r0p3, r0p4, r0p5.
|
| This patch is the SW workaround by adding a DSB before changing cache levels
| as the ARM ERRATA: ARM/MP: 814220 told in the ARM ERRATA documentation.
| Signed-off-by: Jason Liu <r64343@freescale.com>
------------------------------------------------------------------------------

It was later posted to LKML for Linux inclusion, but is not yet mainline:
<20190214083145.15148-1-benjamin.gaignard@linaro.org>

Unlike the Linux version, we don't make the barrier dependent on a
Kconfig option and always execute the dsb:

On 25/4/19 12:02, Lucas Stach wrote:
> I don't think we need a Kconfig option here. This function is not
> really performance critical. The short pipeline stall introduced by the
> dsb when switching the cache level is minor compared to the time it
> takes to actually move the cache blocks on a clean.
>
> Just always execute the [dsb] and add a comment on why it is needed.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: aarch64: lowlevel: Reset SCTLR_EL3 in arm_cpu_lowlevel_init() ...

There's no guarantee that when arm_cpu_lowlevel_init() runs at EL3,
SCTLR will be in a state we expect it to be. Add code to reset it to a
known state, so we'd always start form clean slate. This is also
matches what we've been doing non 64-bit ARMs.

Real word motivation for this patch is i.MX8MQ whose rev 2.1 silicon
appear to have different mask ROM behaviour where it now leaves MMU
enabled if no valid boot source is found. Page table it sets up
doesn't include DDR range, so trying to bootstrap the device via
JTAG/OpenOCD results in an abort.

The value for SCTLR_ELx_FLAGS was taken from Linux kernel.

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

hab/caam: Fix compilation of caam driver when hab is disabled ...

The caam driver needs the variable habv4_need_rng_software_self_test,
but this is only declared when HABV4 is enabled. Instead of exporting
a variable rather provide a function to test if a software selftest
of the random number generator is needed.

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

hab: habv4_need_rng_software_self_test is needed without hab support ...

habv4_need_rng_software_self_test

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

clk: socfpga: fix compiler warnings for Cyclone5 ...

When building for Cyclone5 SoCFPGA, the socfpga_a10_pll_init(),
socfpga_a10_perith_init() and socfpga_a10_gate_init() functions are
defined as dummy functions returning ERR_PTR(-ENOSYS).  They are defined
with external linkage.  With '-Wmissing-prototypes' GCC warns about
externally linked function definitions with no preceding prototype.
Define them as 'static inline' to avoid the compiler warnings.

(Note: Arria10 uses non-dummy versions of these functions declared
'extern' but defined elsewhere.)

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Merge branch 'for-next/zynqmp'

Merge branch 'for-next/warnings'

Merge branch 'for-next/usb-storage'

Merge branch 'for-next/stm32'

Merge branch 'for-next/pstore'

Merge branch 'for-next/net'

Merge branch 'for-next/misc'

Merge branch 'for-next/lseek'

Merge branch 'for-next/layerscape'

Merge branch 'for-next/imx'

Merge branch 'for-next/dts'

dts: update to v5.1-rc3 ...

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

dts: update to v5.1-rc2 ...

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

dts: update to v5.1-rc1 ...

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

Release v2019.04.0 ...

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

commands: unify newlines for options ...

The BAREBOX_CMD_HELP_OPT macro adds a newline to the string, but users
of the macro inconsistently add another newline resulting in empty
newlines for some commands, but not for others. Remove any newline in
the description and rely on BAREBOX_CMD_HELP_OPT for the formatting.

Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: rpi: add board revision for Compute Module 3+ ...

Raspberry Pi Compute Module 3+ was released in January 2019.

Source for the new board revision code:

https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md

Signed-off-by: Tomaz Solc <tomaz.solc@tablix.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>