QorIQ LS1012A Development System (LS1012AQDS) is a high-performance
development platform, with a complete debugging environment.
The LS1012AQDS board supports the QorIQ LS1012A processor and is
optimized to support the high-bandwidth DDR3L memory and
a full complement of high-speed SerDes ports.

Signed-off-by: Calvin Johnson <calvin.johnson@nxp.com>
Signed-off-by: Pratiyush Mohan Srivastava <pratiyush.srivastava@nxp.com>
Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

The QorIQ LS1012A processor, optimized for battery-backed or
USB-powered, integrates a single ARM Cortex-A53 core with a hardware
packet forwarding engine and high-speed interfaces to deliver
line-rate networking performance.

This patch add support of LS1012A SoC along with
 - Update platform & DDR clock read logic as per SVR
 - Define MMDC controller register set.
 - Update LUT base address for PCIe
 - Avoid L3 platform cache compilation
 - Update USB address, errata
 - SerDes table
 - Added CSU IDs for SDHC2, SAI-1 to SAI-4

Signed-off-by: Calvin Johnson <calvin.johnson@nxp.com>
Signed-off-by: Makarand Pawagi <makarand.pawagi@mindspeed.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

SoC overviews are getting repeated across board folders.
So, Organize SoC overview at common location i.e. fsl-layerscape/doc

Also move README.lsch2 and README.lsch3 in same folder.

Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c: In function
‘get_sys_info’:
arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c:29:6: warning:
unused variable ‘rcw_tmp’ [-Wunused-variable]
  u32 rcw_tmp;

Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

Other than LS1043A, LS1012A also Chassis Gen2 Architecture compliant.
So Avoid LS1043A specific defines in arch/arm

Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

It is not mandatory for Layerscape SoCs to have SMMU. SoCs like
LS1012A are layerscape SoC without SMMU IP.

So put SMMU configuration code under SMMU_BASE.

Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

All the output clock parameters of a DPLL needs to be programmed before
locking the DPLL. But it is being configured after locking the DPLL which
could potentially bypass DPLL. So fixing this sequence.

Reported-by: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>

Since 1e6ad55c ("armv8/cache: Change cache invalidate and flush
function"), this routine can be used for both cache flushing and
cache invalidation.  So, it is better to not include "flush" in
this routine name.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

We should say "clean & invalidate", or simply "flush".

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

__asm_dcache_all can directly return to the caller of
__asm_{flush,invalidate}_dcache_all.

We do not have to waste x16 register here.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: York Sun <york.sun@nxp.com>

Add minimal dts support for AM335x-ICEv2 board

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>

The CDCE913 and CDCEL913 devices are modular PLL-based, low cost,
high performance , programmable clock synthesizers. They generate
upto 3 output clocks from a single input frequency. Each output can
be programmed for any clock-frequency.

Adding support for the same.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

AM335x ICEv2 contains a 2Gbit(128Mx16) of DDR3 SDRAM(MT41J128M16JT-125),
capable of running at 400MHz. Adding this specific DDR configuration
details running at 400MHz.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

Add initial DTS support for AM335x-BBG

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

Add initial DTS support for AM335x-evm sk.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

As per mmc device tree binding documentation card detect gpio has
to be active low signal. When a hardware is designed with active
high card detect, gpio polarity has to be changed with
cd-inverted dt property.

In AM335x the card detect gpio is designed as active low gpio.
So correcting the dt card detect gpio definition.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>

Allow am335x-bone.dts to be built and enable uart and timer
for all beaglebones.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

Add initial DTS support for AM437x-IDK evm.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

Add initial DTS support for AM43-EPOS evm.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

Adds an fdt.c file in that defines the ft_cpu_setup() function,
which should be called from a board-specific ft_board_setup()).
This ft_cpu_setup() will currently do nothing for non-secure (GP)
devices	but contains pertinent updates for booting on secure (HS)
devices.

Update the omap5 Makefile to include the fdt.c in the build.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>

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

Update the CPU string output so that the device
type is now included as part of the CPU string that
is printed as the SPL or u-boot comes up. This update
adds a suffix of the form "-GP" or "-HS" for production
devices, so that general purpose (GP) and high security
(HS) can be distiguished. Applies to all OMAP5 variants.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>

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

Updates the SPL build so that when CONFIG_TI_SECURE_DEVICE
is in use (which it should be when building for secure parts),
the TI secure development package is used to create a valid
secure boot image. The u-boot SPL build processes is NOT aware
of the details of creating the boot image - all of that information
is encapsulated in the TI secure development package, which is
available from TI. More info can be found in README.ti-secure

Right now, two image types are generated, MLO and X-LOADER. The types
are important, as certain boot modes implemented by the device's ROM
boot loader require one or the other (they are not equivalent). The
output filenames are u-boot-spl_HS_MLO and u-boot-spl_HS_X-LOADER. The
u-boot-spl_HS_MLO image is also copied to a file named MLO, which is
the name that the device ROM bootloader requires for loading from the
FAT partition of an SD card (same as on non-secure devices).

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Modifies the config.mk to build secure images when building
the SPL for secure devices.

Depending on the boot media, different images are needed
for secure devices. The build generates u-boot*_HS_* files
as appropriate for the different boot modes. The same u-boot
binary file is processed slightly differently to produce a
different boot image, depending on whether the user wants to
boot off SPI, QSPI or other boot media.

Refer to README.ti-secure for more information.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Adds a centralized config_secure.mk in omap-common for
OMAP-style TI secure devices to use for boot image generation

Depending on the boot media, different images are needed for
secure devices. These commands generates u-boot*_HS_* files that
need to be used to boot secure devices.

Please refer to README.ti-secure for more information.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Defines CONFIG_TI_SECURE_DEVICE which needs to be turned on
when building images for secure devices. This flag is used
to invoke the secure image creation tools for creating a
boot image that can be used on secure devices. This flag
may also be used to conditionally compile code specific
to secure devices.

This terminology will be used by all OMAP architecture devices,
hence introducing to a common location.

With the creation of Kconfig for omap-common, moved the
sourcing of the Kconfig files for the omap3/4/5 and am33xx
devices from arch/arm/KConfig to the omap-common one.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Adding support for AM43xx secure devices require the addition
of some SOC specific config options like the amount of memory
used by public ROM and the address of the entry point of u-boot
or SPL, as seen by the ROM code, for the image to be built
correctly.

This mandates the addition of am AM43xx CONFIG option and the
ARM Kconfig file has been modified to source this SOC Kconfig
file. Moving the TARGET_AM43XX_EVM config option to the SOC
KConfig and out of the arch/arm/Kconfig.

Updating defconfigs to add the CONFIG_AM43XX=y statement and
removing the #define CONFIG_AM43XX from the header file.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>

Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Adds a new Kconfig file for AM33xx class devices. We
need a common place to define CONFIG parameters
for these SOCs, especially for adding support
for secure devices.

a) Adds a definition for ISW_ENTRY_ADDR. This is the
address to which the ROM branches when the SOC
ROM hands off execution to the boot loader.
CONFIG_SYS_TEXT_BASE and CONFIG_SPL_TEXT_BASE are set
to this value for AM43xx devices.

b) Adds CONFIG_PUB_ROM_DATA_SIZE which is used to
calculate CONFIG_SPL_MAX_SIZE. This value indicates the
amount of memory needed by the ROM to store data during
the boot process.

Currently, these CONFIG options are used only by AM43xx,
but in future other AM33xx class SOCs will also use them.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Implement calls to secure monitor to read the MAC address from e-fuse.

Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>

This adds platform code for the Amlogic Meson GXBaby (S905) SoC and a
board definition for ODROID-C2. This initial submission only supports
UART and Ethernet (through the existing Designware driver). DTS files
are the ones submitted to Linux arm-soc for 4.7 [1].

[1] https://patchwork.ozlabs.org/patch/603583/



Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Add a psci_system_reset() which calls the SYSTEM_RESET function of
PSCI 0.2 and can be used by boards that support it to implement
reset_cpu().

Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Enable CONFIG_BLK to move to using driver model for block devices. This
affects MMC booting in SPL, as well as MMC access in U-Boot proper.

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

u-boot only recognize okay to enable a node (Linux seems to be more
lenient here). So use okay instead.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Simon Glass <sjg@chromium.org>

Add a definition for the gmac interface to the firefly device-tree.
Copied verbatim from the linux kernel.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Simon Glass <sjg@chromium.org>

Add definitions for GRF_SOC_CON1 and GRF_SOC_CON3 which contain various
GMAC related fields.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Simon Glass <sjg@chromium.org>

Setup the clocks for the gmac ethernet interface. This assumes the mac
clock is fed by an external clock which is common on RK3288 based
devices.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Simon Glass <sjg@chromium.org>

The current reset API implements a method to reset the entire system.
In the near future, I'd like to introduce code that implements the device
tree reset bindings; i.e. the equivalent of the Linux kernel's reset API.
This controls resets to individual HW blocks or external chips with reset
signals. It doesn't make sense to merge the two APIs into one since they
have different semantic purposes. Resolve the naming conflict by renaming
the existing reset API to sysreset instead, so the new reset API can be
called just reset.

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

Recently a set of CONFIG_CMD_FOO defines was moved from being defined
in config_distro_defaults to Kconfig, and added to all sunxi defconfigs
to compensate.

Instead of explictly selecting these in all sunxi defconfigs,
simply always select these for sunxi boards. This makes the defconfigs
simpler and ensures a consistent set of available commands across all
sunxi boards.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>

The originally committed .dts files for the Pine64 were from an early
proof-of-concept version and should have never been committed upstream.
Replace them with much more mature versions, which also use a different
naming scheme.
Please note that at this point there is at least one binding which has
not been agreed upon, so this is subject to change.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

This addresses a cosmetic issue when booting a sunxi device
over USB (FEL mode), where the SPL currently would just print
"Trying to boot from ". The patch fixes that to properly read
"Trying to boot from FEL".

Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

The current SPL header, created by the 'mksunxiboot' tool, has size
32 bytes. But the code in the boot ROM stores the information about
the boot media at the offset 0x28 before passing control to the SPL.
For example, when booting from the SD card, the magic number written
by the boot ROM is 0. And when booting from the SPI flash, the magic
number is 3. NAND and eMMC probably have their own special magic
numbers too.

Currently the corrupted byte is a part of one of the instructions in
the reset vectors table:

    b     reset
    ldr   pc, _undefined_instruction
    ldr   pc, _software_interrupt      <- Corruption happens here
    ldr   pc, _prefetch_abort
    ldr   pc, _data_abort
    ldr   pc, _not_used
    ldr   pc, _irq
    ldr   pc, _fiq

In practice this does not cause any visible problems, but it's still
better to fix it. As a bonus, the reported boot media type can be
later used in the 'spl_boot_device' function, but this is out of
the scope of this patch.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>