The Boot ROM supports authentication feature to prevent malformed
software from being run on products.  The signature is added at the
tail of the second stage loader (= SPL in U-boot terminology).

The size of the second stage loader was 64KB, and it was consistent
across SoCs.  The situation changed when LD20 SoC appeared; it loads
80KB second stage loader, and it is the only exception.

Currently, CONFIG_SPL_PAD_TO is set to 64KB and U-Boot proper is
loaded from the 64KB offset of non-volatile devices.  This means the
signature of LD20 SoC (located at 80KB offset) corrupts the U-Boot
proper image.

Let's move the U-Boot proper image to 128KB offset.  It uses 48KB
for nothing but padding, and we could actually locate the U-Boot
proper at 80KB offset.  However, the power of 2 generally seems a
better choice for the offset address.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

When ARM Trusted Firmware is used, bl1.bin + fip.bin exceeds 512KB,
so the boot image and the current environment area will overlap.
Move the environment storage to 1MB offset.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

The boot_ramdisk_high() checks the environment "initrd_high" and,
if it is set to (ulong)-1, skip the initrd relocation.  This is
useful for faster booting when we know the initrd is already located
within the reach of the kernel.

Change "norboot" to copy images in order to make it work without
depending on the automatic relocation.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

The ARM64 Linux raw image now amounts to 15MB and it is getting
bigger and bigger.  Using Image.gz saves about 8MB.  The cost of
unzip is smaller than what we get by saving the kernel loading
from non-volatile devices.

The ARM32 Linux still uses zImage, a self-decompressor image,
so it should not be affected.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

For clarification, move CONFIG symbols that affect SPL building
into a single place.  Drop #ifdef CONFIG_SPL ... #endif since it is
harmless to define CONFIG_SPL_... during U-Boot proper building.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Now U-Boot proper need not get the uniphier_boards array.  Compile
it only for SPL.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Make it look like cmd_ddrphy.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Just cosmetic changes:
  - Rename prefix DMPHY_ to MPHY_ for consistency
  - Move UMC parameters below for complete decouple of PHY and UMC
  - Remove redundant whitespaces
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

It seems more readable to use arrays to get SoC specific parameters
instead of the crappy switch statement.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

For LD20 SoC, the last 64 byte of each DRAM bank is used for the
dynamic training of DRAM PHY.  The regions must be reserved in DT to
prevent the kernel from using them.  Now gd->bd->bi_dram reflects
the actual memory banks.  Just use it instead of getting access to
the board parameters.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

U-Boot needs to set up available memory area(s) in dram_init() and
dram_init_banksize().  It is platform-dependent how to detect the
memory banks.  Currently, UniPhier adopts the memory banks _alleged_
by DT.  This is based on the assumption that users bind a correct DT
in their build process.

Come to think of it, the DRAM controller has already been set up
before U-Boot is entered (because U-Boot runs on DRAM).  So, the
DRAM controller setup register seems a more reliable source of any
information about DRAM stuff.  The DRAM banks are initialized by
preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever),
so this means the source of the reliability is shifted from Device
Tree to such early-stage firmware.  However, if the DRAM controller
is wrongly configured, the system will crash.  If your system is
running, the DRAM setup register is very likely to provide the
correct DRAM mapping.

Decode the SG_MEMCONF register to get the available DRAM banks.
The dram_init() and dram_init_banksize() need similar decoding.
It would be nice if dram_init_banksize() could reuse the outcome
of dram_init(), but global variables are unavailable at this stage
because the .bss section is available only after the relocation.
As a result, SG_MEMCONF must be checked twice, but a new helper
uniphier_memconf_decode() will help to avoid code duplication.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

The two arrays ddrphy_{op,ip}_dq_shift_val, occupy more than 3.8 KB
memory footprint, which is significant in SPL.

There are PHY parameters for 5 boards, but they are actually not
board specific, but SoC specific.  After all, we just need to have
2 patterns, for LD20 and LD21.  Also, the shift values are small
enough to become "short" type instead of "int".  This change will
save about 3 KB memory footprint.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

I missed to update them when DT files were resynced with Linux.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Commit ec6617c3 ("armv8: Support loading 32-bit OS in AArch32
execution state") broke SMP boot by assuming that an image is 32-bit if
the arch field in the spin table != IH_ARCH_DEFAULT (i.e.
IH_ARCH_ARM64), even if the arch field also does not match IH_ARCH_ARM,
even though nothing actually set the arch field in the spin table.

Commit e2c18e40 ("armv8: fsl-layerscape: SMP support for loading
32-bit OS") fixed this for bootm by setting the arch field of the spin
table based on images.os.arch, but booti remaineed broken because it did
not set images.os.arch.

Fixes: ec6617c3 ("armv8: Support loading 32-bit OS in AArch32 execution state")
Fixes: e2c18e40 ("armv8: fsl-layerscape: SMP support for loading 32-bit OS")
Cc: Alison Wang <alison.wang@nxp.com>
Cc: Chenhui Zhao <chenhui.zhao@nxp.com>
Cc: York Sun <york.sun@nxp.com>
Cc: Stuart Yoder <stuart.yoder@nxp.com>
Signed-off-by: NScott Wood <oss@buserror.net>
Reviewed-by: NTom Rini <trini@konsulko.com>

Doing unaligned reads is not supported on all architectures, use
byte sized reads of the little endian buffer.
Rename off16 to off8, as it reflects the buffer offset in byte
granularity (offset is in entry, i.e. 12 bit, granularity).
Fix a regression introduced in 8d48c92bReported-by: NOleksandr Tymoshenko <gonzo@bluezbox.com>
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Tested-by: NOleksandr Tymoshenko <gonzo@bluezbox.com>

To troubleshoot unexpected bhavior during building and what's more
important during execution it is strongly recommended to use recent
ARC toolchain, and so we're now referring to arc-2016.09 which is the
latest as of today.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This patch adds support for the QSPI IP found in stm32f7 devices.
Signed-off-by: NMichael Kurz <michi.kurz@gmail.com>

This patch enables support for the smsc phy on the
stm32f746-disco board.
Signed-off-by: NMichael Kurz <michi.kurz@gmail.com>
Acked-by: NVikas MANOCHA <vikas.manocha@st.com>

Series-changes 3:
- Add Acked-by tag to 'enable support for smsc phy on...'

This patch adds support for SMSC LAN8742 in phylib
Signed-off-by: NMichael Kurz <michi.kurz@gmail.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

This patch adds glue code required for enabling the designware
mac on stm32f7 devices.
Signed-off-by: NMichael Kurz <michi.kurz@gmail.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Use the clock setup function defined in clock.c instead of setting the
clock bits directly in the drivers.
Remove register definitions of RCC in rcc.h as these are already
defined in the struct in stm32.h
Signed-off-by: NMichael Kurz <michi.kurz@gmail.com>
Reviewed-by: NJoe Hershberger <joe.hershberger@ni.com>
Reviewed-by: NVikas Manocha <vikas.manocha@st.com>

The fmc base address is defined twice, once in fmc.h and once in stm32.h.
Fix wrong definition in stm32.h.
Remove the definiton in fmc.h.
Signed-off-by: NMichael Kurz <michi.kurz@gmail.com>
Acked-by: NVikas Manocha <vikas.manocha@st.com>

Cleanup stm32f7 files:
- use BIT macro
- use GENMASK macro
- use rcc struct instead of macro additions

Add missing stm32f7 register in rcc struct
Signed-off-by: NMichael Kurz <michi.kurz@gmail.com>
Acked-by: Vikas MANOCHA<vikas.manocha@st.com>

This patch adds the DTS source files needed for stm32f746-disco board
The files are based on the stm32f429/469 files from current linux
kernel.

Source for "arch/arm/dts/armv7-m.dtsi": Linux: "arch/arm/boot/dts/armv7-m.dtsi"
Signed-off-by: NMichael Kurz <michi.kurz@gmail.com>
Acked-by: NVikas MANOCHA <vikas.manocha@st.com>

This patch adds pin control definitions for use in device tree files
The definitions are based on the stm32f746 files from current
linux kernel "include/dt-bindings/pinctrl/stm32f746-pinfunc.h".
Signed-off-by: NMichael Kurz <michi.kurz@gmail.com>
Acked-by: NVikas MANOCHA <vikas.manocha@st.com>

The check for OMAP3630/3730 only checks for 800MHz 3630/3730, but
anything else is lumped into 36XX/37XX with an assumed 1GHz speed.

Based on the DM3730 TRM bit 9 shows the MPU Frequency (800MHz/1GHZ).
This also adds the ability to distinguish between the DM3730, DM3725,
AM3715, and AM3703 and correctly display their maximum speed.
Signed-off-by: NAdam Ford <aford173@gmail.com>
Tested-by: NLadislav Michl <ladis@linux-mips.org>

Frequency is measured in Hz.
Signed-off-by: NLadislav Michl <ladis@linux-mips.org>

This reverts commit 8c36e99f.

There is misunderstanding in commit 8c36e99f ("armv8: release
slave cores from CPU_RELEASE_ADDR").  How to bring the slave cores
into U-Boot proper is platform-specific.  So, it should be cared
in SoC/board files instead of common/spl/spl.c.  As you see SPL
is the acronym of Secondary Program Loader, there is generally
something that runs before SPL (the First one is usually Boot ROM).

How to wake up slave cores from the Boot ROM is really SoC specific.
So, the intention for the spin table support is to bring the slave
cores into U-Boot proper in an SoC specific manner.  (this must be
done after relocation.  see below.)

If you bring the slaves into SPL, it is SoC own code responsibility
to transfer them to U-Boot proper.  The Spin Table defines the
interface between a boot-loader and Linux kernel.  It is unrelated
to the interface between SPL and U-Boot proper.

One more thing is missing in the commit; spl_image->entry_point
points to the entry address of U-Boot *before* relocation.  U-Boot
relocates itself between board_init_f() and board_init_r().  This
means the master CPU sees the different copy of the spin code than
the slave CPUs enter.  The spin_table_update_dt() protects the code
*after* relocation.  As a result, the slave CPUs spin in unprotected
code, which leads to unstable behavior.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This feature seems to be sometimes misunderstood.  The intention is:

[1] Bring the slaves into the U-Boot proper image, not SPL (unless
    you have a special reason to do otherwise).

[2] The operation must be done in a board (SoC) specific manner
    since how to wake the slaves from the Boot ROM is SoC specific.

[3] The slaves must enter U-Boot proper after U-Boot relocates
    itself because the "cpu-release-addr" property points to the
    relocated memory area.

[2] is already explained in the help.  We can make [1] even clearer
by mentioning "U-Boot proper" instead of "U-Boot".  [3] is missing,
so I am adding it to the list.  Instead, "before the master CPU
jumps to the kernel" is a matter of course, so removed.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

chiliBoard is a development board which uses chiliSOM as its base.

Hardware specification:
 * chiliSOM (TI AM335x, DRAM, NAND)
 * Ethernet PHY (id 0)
 * USB host (usb1)
 * MicroSD slot (mmc0)
Signed-off-by: NMarcin Niestroj <m.niestroj@grinn-global.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

chiliSOM is a System On Module (http://http://grinn-global.com/chilisom/).
It can't exists on its own, but will be used as part of other boards.

Hardware specification:
 * TI AM335x processor
 * 128M, 256M or 512M DDR3 memory
 * up to 256M NAND

We place source inside arch/arm/mach-omap2/ directory and make it
possible to reuse initialization code (i.e. DDR, NAND init) for all
boards that use it.
Signed-off-by: NMarcin Niestroj <m.niestroj@grinn-global.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Add a new defconfig file for the AM335x High Security EVM. This config
is specific for the case of memory device booting. Memory device booting
is handled separatly from peripheral booting on HS devices as the load
address changes.

This defconfig is the same as for the non-secure part, except for:
	CONFIG_TI_SECURE_DEVICE option set to 'y'
	CONFIG_ISW_ENTRY_ADDR updated for secure images.
	CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'
	CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y'
	CONFIG_USE_TINY_PRINTF option set to 'y' to reduce SPL size
	CONFIG_SPL_SYS_MALLOC_SIMPLE set to 'y' to reduce SPL size
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

spl_init on some boards is called after stack and heap relocation, on
some platforms spl_relocate_stack_gd is called to handle setting the
limit to its value CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN when simple
SPL malloc is enabled during relocation. spl_init should then not
re-assign the old pre-relocation limit when this is defined.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Add debug statements to memalign_simple to match malloc_simple.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

ast2500 Eval Board device tree and board specific configuration.
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add configuration file with parameters that are very likely to be shared by
all ast2500-based boards.
Add ast2500-board.c file with the init code that is very likely to be
shared by all ast2500-based boards.
Reviewed-by: NSimon Glass <sjg@chromium.org>

Clock Driver

This driver is ast2500-specific and is not compatible with earlier
versions of this chip. The differences are not that big, but they are
in somewhat random places, so making it compatible with ast2400 is not
worth the effort at the moment.

SDRAM MC driver

The driver is very ast2500-specific and is completely incompatible
with previous versions of the chip.

The memory controller is very poorly documented by Aspeed in the
datasheet, with any mention of the whole range of registers missing. The
initialization procedure has been basically taken from Aspeed SDK, where
it is implemented in assembly. Here it is rewritten in C, with very limited
understanding of what exactly it is doing.
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add support for Watchdog Timer, which is compatible with AST2400 and
AST2500 watchdogs. There is no uclass for Watchdog yet, so the driver
does not follow the driver model. It also uses fixed clock, so no clock
driver is needed.

Add support for timer for Aspeed ast2400/ast2500 devices.
The driver actually controls several devices, but because all devices
share the same Control Register, it is somewhat difficult to completely
decouple them. Since only one timer is needed at the moment, this should
be OK. The timer uses fixed clock, so does not rely on a clock driver.

Add sysreset driver, which uses watchdog timer to do resets and particular
watchdog device to use is hardcoded (0)
Reviewed-by: NSimon Glass <sjg@chromium.org>

In the cases of some boards, a MACH_TYPE number is used which is either
not registered upstream or worse (for functionality) is re-using the
number of a different (or reference) platform instead.  Make sure we
have a comment in these cases.

Cc: Albert ARIBAUD <albert.aribaud@3adev.fr>
Cc: Walter Schweizer <swwa@users.sourceforge.net>
Cc: Stefan Roese <sr@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NTom Rini <trini@konsulko.com>
Acked-by: NStefan Roese <sr@denx.de>

This board is using MACH_TYPE values that were clearly picked during
development and not registered.  Remove rather than support.

Cc: Heiko Schocher <hs@denx.de>
Signed-off-by: NTom Rini <trini@konsulko.com>