FPGA changes for v2018.11

- add fpga tests to cover fpga commands
- fpga Kconfig cleanup
- fix cmd/fpga.c
- add support for missing fpga loadmk commands
- add fpga fragment to MAINTAINERS

Add initial defconfig support for AM65x that runs on A53.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Add the minimum dt nodes required to boot. These nodes
will get deleted as kernel gets these nodes added in the
main dts files.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Add initial DT support for AM654 EVM that runs on A53.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Create a basic U-Boot environment that allows the automatic loading
of a Linux Kernel located at /boot/Image and an associated device tree
blob located at /boot/k3-am654-base-board.dtb from the secondary
partition of an ext4-formatted SD card on the AM654x EVM. Furthermore
the boot.scr and uEnv.txt detection and loading schemes are supported
in a manner already known from other TI platforms.

Note that this is intended to be a starting point to enable initial
board use and will most certainly get extended and refactored as
different boot media become available.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Add initial support for AM654 based EVM running on A53. Enable
4GB of DDR available on the EVM so that kernel DTB file
can be updated accordingly.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
[Andreas: Added 4GB ddr support]
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>

As no gpio.h is defined in arch/arm/mach-k3/include/,
to avoid compilation failure, do not include asm/arch/gpio.h.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

AM654 has an arasan sdhci controller and a mmc phy attached to it.
Add basic support for K3 specific arasan sdhci controller.

Cc: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Add an option for building remoteproc drivers within SPL.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Add support for K3 based remoteproc driver that
communicates with TISCI to start start a remote processor.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

K3 specific SoCs have a dedicated microcontroller for doing
resource management. Any HLOS/firmware on compute clusters should
load a firmware to this microcontroller before accessing any resource.
Adding support for loading this firmware.

After the K3 system controller got loaded with firmware and started
up it sends out a boot notification message through the secure proxy
facility using the TI SCI protocol. Intercept and receive this message
through the rproc start operation which will need to get invoked
explicitly after the firmware got loaded.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Existing rproc_init() api tries to initialize all available
remoteproc devices. This will fail when there is dependency
among available remoteprocs. So introduce a separate api
that allows to initialize remoteprocs individually based
on id.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Add an option for building mailbox drivers within SPL.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Secure Proxy module manages hardware threads that are meant
for communication between the processor entities. Adding
support for this driver.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>

Sometimes mbox controllers wants to store private data in
mbox_chan so that it can be used at a later point of time.
Adding support for hooking private data.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Devices from the TI K3 family of SoCs like the AM654x contain a Device
Management and Security Controller (SYSFW) that manages the low-level
device control (like clocks, resets etc) for the various hardware
modules present on the SoC. These device control operations are provided
to the host processor OS through a communication protocol called the TI
System Control Interface (TI SCI) protocol.

This patch adds a system reset driver that communicates to the system
controller over the TI SCI protocol for allowing to perform a system-
wide SoC reset.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Some TI Keystone 2 and K3 family of SoCs contain a system controller
(like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and
the Device Management and Security Controller on AM65x SoCs) that manage
the low-level device control (like clocks, resets etc) for the various
hardware modules present on the SoC. These device control operations are
provided to the host processor OS through a communication protocol
called the TI System Control Interface (TI SCI) protocol.

This patch adds a power domain driver that communicates to the system
controller over the TI SCI protocol for performing power management of
various devices present on the SoC. Various power domain functionalities
are achieved by the means of different TI SCI device operations provided
by the TI SCI framework.

This code is loosely based on the drivers/soc/ti/ti_sci_pm_domains.c
driver of the Linux kernel.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

There are cases where there are more than one power domain
attached to the device inorder to get the device functional.
So add support for enabling power domain based on the index.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Some TI Keystone 2 and K3 family of SoCs contain a system controller
(like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and
the Device Management and Security Controller on AM65x SoCs) that manage
the low-level device control (like clocks, resets etc) for the various
hardware modules present on the SoC. These device control operations are
provided to the host processor OS through a communication protocol
called the TI System Control Interface (TI SCI) protocol.

This patch adds a clock driver that communicates to the system
controller over the TI SCI protocol for performing clock management of
various devices present on the SoC. Various clock functionality is
achieved by the means of different TI SCI device operations provided by
the TI SCI framework.

This code is loosely based on the drivers/clk/keystone/sci-clk.c driver
of the Linux kernel.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Some systems require more than a single ID to identify and configure any
clock provider. For those scenarios add an optional data field to the
clock control structure.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Some TI Keystone 2 and K3 family of SoCs contain a system controller
(like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and
the Device Management and Security Controller on AM65x SoCs) that manage
the low-level device control (like clocks, resets etc) for the various
hardware modules present on the SoC. These device control operations are
provided to the host processor OS through a communication protocol
called the TI System Control Interface (TI SCI) protocol.

This patch adds a reset driver that communicates to the system
controller over the TI SCI protocol for performing reset management of
various devices present on the SoC. Various reset functionalities are
achieved by the means of different TI SCI device operations provided by
the TI SCI framework.

This code is loosely based on the drivers/reset/reset-ti-sci.c driver of
the Linux kernel.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Some systems require more than a single ID to identify and configure any
reset provider. For those scenarios add an optional data field to the
reset control structure.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Add a reset operations function pointer to support querying the current
status of a reset control.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

To support scenarios where a firmware device node has subnodes that
have their own drivers automatically scan the DT and bind those when
the firmware device gets bound.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

TI-SCI message protocol provides support for controlling of various
physical cores available in SoC. In order to control which host is
capable of controlling a physical processor core, there is a processor
access control list that needs to be populated as part of the board
configuration data.

Introduce support for the set of TI-SCI message protocol apis that
provide us with this capability of controlling physical cores.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Since system controller now has control over SoC power management, it
needs to be explicitly requested to reboot the SoC. Add support for
it.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>

In general, we expect to function at a device level of abstraction,
however, for proper operation of hardware blocks, many clocks directly
supplying the hardware block needs to be queried or configured.

Introduce support for the set of SCI message protocol support that
provide us with this capability.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>

TI-SCI message protocol provides support for management of various
hardware entitites within the SoC. Introduce the fundamental
device management capability support to the driver protocol
as part of this change.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>

TI-SCI message protocol provides support for board configuration
to assign resources and other board related operations.
Introduce the board configuration capability support to the driver protocol
as part of this change.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Texas Instrument's System Control Interface (TI SCI) message protocol is
used in Texas Instrument's System on Chip (SoC) such as those in the K3
family AM654 SoC to communicate between various compute processors with
a central system controller entity.

The TI SCI message protocol provides support for management of various
hardware entities within the SoC. Add support driver to allow
communication with system controller entity within the SoC using the
mailbox client.

This is mostly derived from the TI SCI driver in Linux located at
drivers/firmware/ti_sci.c.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>

Update Makefile to generate
- tispl.bin: First stage bootloader on ARMv8 core
- u-boot.img: Second stage bootloader on ARMv8 core.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Add a script that is capable of generating a FIT image
source file that combines ATF, SPL(64 bit) and DT.
This combined image is used by R5 SPL and start ATF
on ARMv8 core.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Add MMU mappings for AM654 SoC.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

By default the device control module registers are locked,
preventing any writes to its registers.
Unlock those registers as part of the init flow.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

AM654 allows for booting from primary or backup boot media.
Both media can be chosen individually based on switch settings.
ROM looks for a valid image in primary boot media, if not found
then looks in backup boot media. In order to pass this boot media
information to boot loader, ROM stores a value at a particular
address. Add support for reading this information and determining
the boot media correctly.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NVignesh R <vigneshr@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

On K3 family SoCs, once the ROM loads image on R5, M3 resets R5 and
expects to start executing from 0x0. In order to handle this ROM
updates the boot vector of R5 such that first 64 bytes of image load
address are mapped to 0x0.

In this case, it is SPL's responsibility to jump to the proper image
location. So, update the PC with address of reset vector(like how
other exception vectors are handled), instead of branching to reset.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

The AM654 device is designed for industrial automation and PLC
controller class platforms among other applications. Introduce
base support for AM654 SoC.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Add support for Texas Instruments' K3 Generation Processor
families.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

FPGA subsystem requires special care that's why it should be maintained
via one tree.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Convert last loads command to fpga subcommands.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>