arm: spl: Avoid setting up a duplicate global data structure

This is already set up in crt0.S. We don't need a new structure and don't
really want one in the 'data' section of the image, since it wi

arm: spl: Avoid setting up a duplicate global data structure

This is already set up in crt0.S. We don't need a new structure and don't
really want one in the 'data' section of the image, since it will be empty
and crt0.S's changes will be ignored.

As an interim measure, remove it only if CONFIG_DM is not defined. This
allows us to press ahead with driver model in SPL and allow the stragglers
to catch up.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

ARM: tegra: pinmux: add Tegra210 support

This patch incorporates a few fixes from Tom Warren <twarren@nvidia.com>.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twar

ARM: tegra: pinmux: add Tegra210 support

This patch incorporates a few fixes from Tom Warren <twarren@nvidia.com>.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

show more ...

ARM: tegra: pinmux: support Tegra210's e_io_hv pin option

Tegra210 has a per-pin option named e_io_hv, which indicates that the
pin's input path should be configured to be 3.3v-tolerant. Add support

ARM: tegra: pinmux: support Tegra210's e_io_hv pin option

Tegra210 has a per-pin option named e_io_hv, which indicates that the
pin's input path should be configured to be 3.3v-tolerant. Add support
for this.

Note that this is very similar to previous chip's rcv_sel option.
However, since the Tegra TRM names this option differently for the
different chips, we support the new name so that the code exactly matches
the naming in the TRM, to avoid confusion.

This patch incorporates a few fixes from Tom Warren <twarren@nvidia.com>.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

show more ...

ARM: tegra: pinmux: account for different drivegroup base registers

Tegra210 starts its drive group registers at a different offset from the
APB MISC register block that other SoCs. Update the code

ARM: tegra: pinmux: account for different drivegroup base registers

Tegra210 starts its drive group registers at a different offset from the
APB MISC register block that other SoCs. Update the code to handle this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

show more ...

ARM: tegra: pinmux: support hsm/schmitt on pins

T210 support HSM and Schmitt options in the pinmux register (previous
chips placed these options in the drive group register). Update the
code to hand

ARM: tegra: pinmux: support hsm/schmitt on pins

T210 support HSM and Schmitt options in the pinmux register (previous
chips placed these options in the drive group register). Update the
code to handle this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

show more ...

ARM: tegra: pinmux: move some type definitions

On some future SoCs, some per-drive-group features became per-pin
features. Move all type definitions early in the header so they can
be enabled irresp

ARM: tegra: pinmux: move some type definitions

On some future SoCs, some per-drive-group features became per-pin
features. Move all type definitions early in the header so they can
be enabled irrespective of the setting of TEGRA_PMX_SOC_HAS_DRVGRPS.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

show more ...

ARM: tegra: pinmux: handle feature removal on newer SoCs

On some future SoCs, some of the per-drive-group features no longer
exist. Add some ifdefs to support this.

Signed-off-by: Stephen Warren <s

ARM: tegra: pinmux: handle feature removal on newer SoCs

On some future SoCs, some of the per-drive-group features no longer
exist. Add some ifdefs to support this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

show more ...

ARM: tegra: pinmux: simplify some defines

Future SoCs have a slightly different combination of pinmux options per
pin. This will be simpler to handle if we simply have one define per
option, rather

ARM: tegra: pinmux: simplify some defines

Future SoCs have a slightly different combination of pinmux options per
pin. This will be simpler to handle if we simply have one define per
option, rather than grouping various options together, in combinations
that don't align with future chips.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

show more ...

ARM: tegra: add function to clear pinmux CLAMPING bit

This is needed to correctly apply the new Jetson TK1 pinmux config.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass

ARM: tegra: add function to clear pinmux CLAMPING bit

This is needed to correctly apply the new Jetson TK1 pinmux config.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>

show more ...

ARM: tegra: support running in non-secure mode

When the CPU is in non-secure (NS) mode (when running U-Boot under a
secure monitor), certain actions cannot be taken, since they would need
to write t

ARM: tegra: support running in non-secure mode

When the CPU is in non-secure (NS) mode (when running U-Boot under a
secure monitor), certain actions cannot be taken, since they would need
to write to secure-only registers. One example is configuring the ARM
architectural timer's CNTFRQ register.

We could support this in one of two ways:
1) Compile twice, once for secure mode (in which case anything goes) and
once for non-secure mode (in which case certain actions are disabled).
This complicates things, since everyone needs to keep track of
different U-Boot binaries for different situations.
2) Detect NS mode at run-time, and optionally skip any impossible actions.
This has the advantage of a single U-Boot binary working in all cases.

(2) is not possible on ARM in general, since there's no architectural way
to detect secure-vs-non-secure. However, there is a Tegra-specific way to
detect this.

This patches uses that feature to detect secure vs. NS mode on Tegra, and
uses that to:

* Skip the ARM arch timer initialization.

* Set/clear an environment variable so that boot scripts can take
different action depending on which mode the CPU is in. This might be
something like:
if CPU is secure:
load secure monitor code into RAM.
boot secure monitor.
secure monitor will restart (a new copy of) U-Boot in NS mode.
else:
execute normal boot process

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

show more ...

Merge branch 'xnext/zynqmp' of git://www.denx.de/git/u-boot-microblaze

arm64: Add Xilinx ZynqMP support

Add basic Xilinx ZynqMP arm64 support.
Serial and SD is supported.
It supports emulation platfrom ep108 and QEMU.

Signed-off-by: Michal Simek <michal.simek@xilinx.c

arm64: Add Xilinx ZynqMP support

Add basic Xilinx ZynqMP arm64 support.
Serial and SD is supported.
It supports emulation platfrom ep108 and QEMU.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

show more ...

armv7.h: Add <asm/io.h>

With a389531 we now call readl() from this file so add <asm/io.h> so
that we have a prototype for the function.

Signed-off-by: Tom Rini <trini@konsulko.com>

imx6: Added DEK blob generator command

Freescale's SEC block has built-in Data Encryption
Key(DEK) Blob Protocol which provides a method for
protecting a DEK for non-secure memory storage.
SEC block

imx6: Added DEK blob generator command

Freescale's SEC block has built-in Data Encryption
Key(DEK) Blob Protocol which provides a method for
protecting a DEK for non-secure memory storage.
SEC block protects data in a data structure called
a Secret Key Blob, which provides both confidentiality
and integrity protection.
Every time the blob encapsulation is executed,
a AES-256 key is randomly generated to encrypt the DEK.
This key is encrypted with the OTP Secret key
from SoC. The resulting blob consists of the encrypted
AES-256 key, the encrypted DEK, and a 16-bit MAC.

During decapsulation, the reverse process is performed
to get back the original DEK. A caveat to the blob
decapsulation process, is that the DEK is decrypted
in secure-memory and can only be read by FSL SEC HW.
The DEK is used to decrypt data during encrypted boot.

Commands added
--------------
dek_blob - encapsulating DEK as a cryptgraphic blob

Commands Syntax
---------------
dek_blob src dst len

Encapsulate and create blob of a len-bits DEK at
address src and store the result at address dst.

Signed-off-by: Raul Cardenas <Ulises.Cardenas@freescale.com>
Signed-off-by: Nitin Garg <nitin.garg@freescale.com>

Signed-off-by: Ulises Cardenas <ulises.cardenas@freescale.com>

Signed-off-by: Ulises Cardenas-B45798 <Ulises.Cardenas@freescale.com>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot

Merge branch 'master' of git://git.denx.de/u-boot-samsung

Merge branch 'master' of git://git.denx.de/u-boot-uniphier

Merge branch 'rmobile' of git://git.denx.de/u-boot-sh

ARM: UniPhier: move SoC headers to mach-uniphier/include/mach

Move arch/arm/include/asm/arch-uniphier/*
-> arch/arm/mach-uniphier/include/mach/*

Signed-off-by: Masahiro Yamada <yamada.m@jp.panaso

ARM: UniPhier: move SoC headers to mach-uniphier/include/mach

Move arch/arm/include/asm/arch-uniphier/*
-> arch/arm/mach-uniphier/include/mach/*

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>

show more ...

Exynos: Fix L2 cache timings on Exynos5420 and Exynos5800

It was found that the L2 cache timings that we had before could cause
freezes and hangs. We should make things more robust with better
timi

Exynos: Fix L2 cache timings on Exynos5420 and Exynos5800

It was found that the L2 cache timings that we had before could cause
freezes and hangs. We should make things more robust with better
timings. Currently the production ChromeOS kernel applies these
timings, but it's nice to fixup firmware too (and upstream probably
won't take our kernel hacks).

This also provides a big cleanup of the L2 cache init code avoiding
some duplication. The way things used to work:
* low_power_start() was installed by the SPL (both at boot and resume
time) and left resident in iRAM for the kernel to use when bringing
up additional CPUs. It used configure_l2_ctlr() and
configure_l2_actlr() when it detected it was on an A15. This was
needed (despite the L2 cache registers being shared among all A15s)
because we might have been the first man in after the whole A15
cluster was shutdown.
* secondary_cores_configure() was called on at boot time and at resume
time. Strangely this called configure_l2_ctlr() but not
configure_l2_actlr() which was almost certainly wrong. Given that
we'll call both (see next bullet) later in the boot process it
didn't matter for normal boot, but I guess this is how L2 cache
settings got set on 5420/5800 (but not 5250?) at resume time.
* exynos5_set_l2cache_params() was called as part of cache enablement.
This should happen at boot time (normally in the SPL except for USB
boot where it happens in main U-Boot).

Note that the old code wasn't setting ECC/parity in the cache
enablement code but we happened to get it anyway because we'd call
secondary_cores_configure() at boot time. For resume time we'd get it
anyway when the 2nd A15 core came up.

Let's make this a whole lot simpler. Now we always set these
parameters in the same place for all boots and use the same code for
setting up secondary CPUs.

Intended net effects of this change (other than cleanup):
* Timings go from before:
data: 0 cycle setup, 3 cycles (0x2) latency
tag: 0 cycle setup, 3 cycles (0x2) latency
after:
data: 1 cycle setup, 4 cycles (0x3) latency
tag: 1 cycle setup, 4 cycles (0x3) latency
* L2ACTLR is properly initted on 5420/5800 in all cases.

One note is that we're still relying on luck to keep low_power_start()
working. The compiler is being nice and not storing anything on the
stack.

Another note is that on its own this patch won't help to fix cache
settings in an RW U-Boot update where we still have the RO SPL. The
plan for that is:
* Have RW U-Boot re-init the cache right before calling the kernel
(after it has turned the L2 cache off). This is why the functions
are in a header file instead of lowlevel_init.c.

* Have the kernel save the L2 cache settings of the boot CPU and apply
them to all other CPUs. We get a little lucky here because the old
code was using "|=" to modify the registers and all of the bits that
it's setting are also present in the new settings (!). That means
that when the 2nd CPU in the A15 cluster comes up it doesn't
actually mess up the settings of the 1st CPU in the A15 cluster. An
alternative option is to have the kernel write its own
low_power_start() code.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Akshay Saraswat <akshay.s@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

show more ...

Exynos542x: Fix secondary core booting for thumb

When compiled SPL for Thumb secondary cores failed to boot
at the kernel boot up. Only one core came up out of 4.
This was happening because the code

Exynos542x: Fix secondary core booting for thumb

When compiled SPL for Thumb secondary cores failed to boot
at the kernel boot up. Only one core came up out of 4.
This was happening because the code relocated to the
address 0x02073000 by the primary core was an ARM asm
code which was executed by the secondary cores as if it
was a thumb code.
This patch fixes the issue of secondary cores considering
relocated code as Thumb instructions and not ARM instructions
by jumping to the relocated with the help of "bx" ARM instruction.
"bx" instruction changes the 5th bit of CPSR which allows
execution unit to consider the following instructions as ARM
instructions.

Signed-off-by: Akshay Saraswat <akshay.s@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

show more ...

Exynos542x: Add workaround for ARM errata 799270

This patch adds workaround for the ARM errata 799270 which says
"If the L2 cache logic clock is stopped because of L2 inactivity,
setting or clearing

Exynos542x: Add workaround for ARM errata 799270

This patch adds workaround for the ARM errata 799270 which says
"If the L2 cache logic clock is stopped because of L2 inactivity,
setting or clearing the ACTLR.SMP bit might not be effective. The bit is
modified in the ACTLR, meaning a read of the register returns the
updated value. However the logic that uses that bit retains the previous
value."

Signed-off-by: Kimoon Kim <kimoon.kim@samsung.com>
Signed-off-by: Akshay Saraswat <akshay.s@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

show more ...

Exynos542x: Add workaround for ARM errata 798870

This patch adds workaround for ARM errata 798870 which says
"If back-to-back speculative cache line fills (fill A and fill B) are
issued from the L1

Exynos542x: Add workaround for ARM errata 798870

This patch adds workaround for ARM errata 798870 which says
"If back-to-back speculative cache line fills (fill A and fill B) are
issued from the L1 data cache of a CPU to the L2 cache, the second
request (fill B) is then cancelled, and the second request would have
detected a hazard against a recent write or eviction (write B) to the
same cache line as fill B then the L2 logic might deadlock."

Signed-off-by: Kimoon Kim <kimoon.kim@samsung.com>
Signed-off-by: Akshay Saraswat <akshay.s@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

show more ...

Exynos542x: CPU: Power down all secondary cores

This patch adds code to shutdown secondary cores.
When U-boot comes up, all secondary cores appear powered on,
which is undesirable and causes side ef

Exynos542x: CPU: Power down all secondary cores

This patch adds code to shutdown secondary cores.
When U-boot comes up, all secondary cores appear powered on,
which is undesirable and causes side effects while
initializing these cores in kernel.

Secondary core power down happens in following steps:

Step-1: After Exynos power-on, primary core starts executing first.
Step-2: In iROM code every core has to check 2 flags i.e.
addresses 0x02020028 & 0x02020004.
Step-3: Initially 0x02020028 is 0 for all cores and 0x02020004 has a
jump address for primary core and 0 for all secondary cores.
Step-4: Therefore, primary core follows normal iROM execution and jumps
to BL1 eventually, whereas all secondary cores enter WFE.
Step-5: When primary core comes into function secondary_cores_configure,
it puts pointer to function power_down_core into 0x02020004
and provides DSB and SEV for all cores so that they may come out
of WFE and jump to power_down_core function.
Step-6: And ultimately because of power_down_core all
secondary cores shut-down.

Signed-off-by: Kimoon Kim <kimoon.kim@samsung.com>
Signed-off-by: Akshay Saraswat <akshay.s@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-fsl-qoriq