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

Revert "ARM: da850evm_direct_nor_defconfig: Enable DM_SERIAL"

This commit is breaking several variants of da850, so:

This reverts commit 5f389201dece76b484443773dce2525dc205f5a1.

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

am3517_evm: Drop inadvertently added line

I added in the CONFIG_MISC_INIT_R line by mistake when applying the
previous patch, fix.

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

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

fs: ubifs: Add missing newlines in super.c

I just stumbled over some cluttered UBIFS messages. It seems some
newline chars are missing in the current U-Boot UBI source.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>

i2c: Drop CONFIG_SYS_I2C_MXS

Last user of this driver went away in May 2017, in
commit eb5ba3aefdf0f6 ("i2c: Drop use of CONFIG_I2C_HARD")

Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>

MMC: davinici_mmc: Enable CD and WP with DM and OF_CONTROL

When used with a device tree, this will extract the card detect
and write protect pins from the device tree and configure them
accordingly.  This assumes the GPIO_ACTIVE_LOW/HIGH is supported
by da8xx_gpio.

Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: am3517_evm: Disable DM_I2C_COMPAT

DM_I2C_COMPAT is somehow being enabled outside of Kconfig, so
this explicitly undefines it in the header file, and brackets
the I2C initialization around an #ifdef to not manually
initialize the I2C controller when the DM_I2C is enabled.

Signed-off-by: Adam Ford <aford173@gmail.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>

Configs: am3517_evm: Remove TWL4030 reference

This SOM and kit do not nor have they ever had a twl4030 PMIC.
This patch removes the references to it.

Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: omap3_logic: Enable DM_PMIC and DM_REGULATOR

Enabling DM_PMIC, DM_REGULATOR_FIXED, and DM_REGULATOR_GPIO
gives us the ability to better monitor voltages and enable
hardware through the device tree. The TL4030 (TPS65950) is
not yet migrated to DM, so this patch only enables the fixed
and GPIO controlled regulators.

Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: da850evm_direct_nor_defconfig: Enable DM_SERIAL

With DM enabled, this patch enables DM_SERIAL and removes
the NS16550 initialization from da850_lowlevel since the driver
will take care of that itself.

Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: davinci: omapl138_lcdk: Enable DM_MMC

With DM_MMC now available, this patch enables DM_MMC for the
omapl138_lcdk in U-Boot and keeps the older style for SPL.

Signed-off-by: Peter Howard <phoward@gme.net.au>
Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: davinci: da850evm: Support DM_MMC

With the updated driver available to support DM_MMC, this patch
enables DM_MMC for da850evm.

Signed-off-by: Adam Ford <aford173@gmail.com>

MMC: Enable DM_MMC for Davinci

With CONFIG_BLK becoming a requirement, the Davinci MMC driver
needs to be updated with DM_MMC support.  Since SPL is tiny and
many boards do not support DM in SPL, this retains the backwards
compatibility for those boards who need to initialize MMC manually
in SPL.

Signed-off-by: Peter Howard <phoward@gme.net.au>
Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: omap3_logic: Enable Pinctrl

The simple pinctrl driver currently available works with the omap3.
Enabling this will use the device tree to automatically set the
pin-muxing for various drivers.

Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: omap3_logic_defconfig: Convert to DM_SPL

The OF_CONTROL and OF_PLATDATA are not really useful without DM.
This patch supports DM_SPL, but it requires manual references
both Serial and MMC.

Signed-off-by: Adam Ford <aford173@gmail.com>

mmc: omap_hsmmc: Make DM_GPIO calls dependent on DM_GPIO

The getcd and getwp functions when DM_MMC is enabled are
assumming the DM_GPIO is enabled.  In cases (like SPL) where
DM_GPIO may not be enabled, wrap these calls in an #ifdef

Signed-off-by: Adam Ford <aford173@gmail.com>

DM: serial: ti_omap3_common: Don't define serial unless !DM_SERIAL

The serial port was being manually configured during SPL build,
however in preparation to allow DM in SPL, this needs to change
to be based on whether or not DM_SERIAL is enabled because, soon
the assumption that SPL means no DM may not be accurate.

Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

ARM: mach-omap2: Don't initialize I2C if DM_I2C is enabled

boot-common.c checks to see if I2C is enabled in SPL, but
it doens't check for DM_I2C before initializing it.  This
will now only initialize the I2C is the DM_I2C is not enabled
to avoid initializing it more than once.

Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

DM: omap_gpio: Reduce overhead when used with OF_PLATDATA

Platforms with limited resources in SPL may enable OF_PLATDATA,
this limits some of the library functions and cannot extract data
from the device tree.  This patch adds additional wrappers around
these functions to only allow them when OF_CONTROL is enabled and
OF_PLATDATA is not.

Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

DM: OMAP24XX_I2C: Reduce overhead when used with OF_PLATDATA

Platforms with limited resources in SPL may enably OF_PLATDATA,
this limits some of the library functions and cannot extract data
from the device tree.  This patch adds additional wrappers around
these functions to only allow them when OF_CONTROL is enabled and
OF_PLATDATA is not.

Signed-off-by: Adam Ford <aford173@gmail.com>

DM: I2C: Reduce overhead when used with OF_PLATDATA

Platforms with limited resources in SPL may enably OF_PLATDATA,
this limits some of the library functions and cannot extract data
from the device tree.  This patch adds additional wrappers around
these functions to only allow them when OF_CONTROL is enabled and
OF_PLATDATA is not.

Signed-off-by: Adam Ford <aford173@gmail.com>

regulator: pbias: Add additional compatible flags

The driver was developed with references for more than just
dra7, but never included.  At least for omap3, this appears
to be functional.

Signed-off-by: Adam Ford <aford173@gmail.com>

GPIO: omap_gpio: Fix gpio name names with device tree

The GPIO bank numbers do not appear in the device tree, so this
patch makes the gpio name based on the address
(ie gpio@49054000_31 vs gpio4_31)

adam

Signed-off-by: Adam Ford <aford173@gmail.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>

ARM: dts: da850-evm-u-boot: Remove redundant entries

With the re-sync from Linux 4.18, several entries in
da850-evm-u-boot.dtsi are no longer necessary, so this patch
removes them.

Signed-off-by: Adam Ford <aford173@gmail.com>

arm: dts: da850: Re-sync da850-evm.dts from Linux 4.18

Signed-off-by: Adam Ford <aford173@gmail.com>

dm: gpio: da8xx_gpio: Add support for GPIO_ACTIVE_LOW/HIGH

With DM and device tree support, let's use the GPIO_ACTIVE_HIGH
and GPIO_ACTIVE_LOW from the device tree as they are intended.

Signed-off-by: Adam Ford <aford173@gmail.com>

DM: GPIO: Fix da8xx GPIO indexing over GPIO 32

The GPIO banks are broken up into two 16-bit registers for each
bank set.  Unfortunately, the math that determines how to shift
blindly shifted by the number of the gpio.  This worked for gpio
numbers under 32, but higher gpio's are broken.  This fixes the
gpio index, so the bank is passed and the shift amount within
the register is passed now instead of the gpio number.

Fixes: 8e51c0f25406("dm: gpio: Add DM compatibility to
GPIO driver for Davinci")

Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: configs: Add da850evm_nand to boot from NAND

The DA850-EVM supports booting from NAND when used with the
UI expander board.  da850evm_nand will create an ais file
that can be burned to NAND and booted while storing the env in
NAND along with some partitions tables for storing kernel,
dtb and rootfs in NAND.

Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: da850evm_direct_nor: Enable CONFIG_BLK

At least for now, CONFIG_BLK is working, but this variant of
the da850evm doesn't need/support SPL so it's OK to enable it
here.

Signed-off-by: Adam Ford <aford173@gmail.com>

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

Merge tag 'fpga-for-v2018.11' of git://git.denx.de/u-boot-microblaze

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

configs: am65x_evm_a53: Add initial support

Add initial defconfig support for AM65x that runs on A53.

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

arm64: dts: k3: Add u-boot specific nodes

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

arm64: dts: k3: Add Support for AM654 SoC

Add initial DT support for AM654 EVM that runs on A53.

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

include: am654_evm: Establish initial environment for SD card boot

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

board: ti: am654: a53: Add initial support for am654

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[Andreas: Added 4GB ddr support]
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>

gpio: do not include <asm/arch/gpio.h> for ARCH_K3

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

mmc: k3_arasan: Add sdhci driver support for K3 family SoCs

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

spl: Allow remoteproc drivers to be used within SPL

Add an option for building remoteproc drivers within SPL.

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

remoteproc: Introduce K3 remoteproc driver

Add support for K3 based remoteproc driver that
communicates with TISCI to start start a remote processor.

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

remoteproc: Introduce K3 system controller

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: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

remoteproc: Allow for individual remoteproc initialization

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

spl: Allow mailbox drivers to be used within SPL

Add an option for building mailbox drivers within SPL.

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

mailbox: Introduce K3 Secure Proxy Driver

Secure Proxy module manages hardware threads that are meant
for communication between the processor entities. Adding
support for this driver.

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

mailbox: Allow attaching private data for mbox_chan

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

sysreset: Add TI System Control Interface (TI SCI) sysreset driver

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

power domain: Introduce TI System Control Interface (TI SCI) power domain driver

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

power domain: Add support for multiple powerdomains per device

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

clk: Introduce TI System Control Interface (TI SCI) clock driver

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

clk: Extend clock control with an optional data field

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

reset: Introduce TI System Control Interface (TI SCI) reset driver

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

reset: Extend reset control with an optional data field

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

dm: reset: Update uclass to allow querying reset status

Add a reset operations function pointer to support querying the current
status of a reset control.

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

dm: firmware: Automatically bind child devices

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

firmware: ti_sci: Add support for processor control services

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

firmware: ti_sci: Add support for reboot core service

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>

firmware: ti_sci: Add support for clock control

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>

firmware: ti_sci: Add support for device control

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>

firmware: ti_sci: Add support for board configuration

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

firmware: Add basic support for TI System Control Interface (TI SCI) protocol

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>

armv8: K3: am654: Add support for generating build targets

Update Makefile to generate
- tispl.bin: First stage bootloader on ARMv8 core
- u-boot.img: Second stage bootloader on ARMv8 core.

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

armv8: K3: am654: Introduce FIT generator script

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: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

armv8: K3: am654: Add custom MMU support

Add MMU mappings for AM654 SoC.

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

arm: K3: am654: Unlock control module registers during init

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

arm: K3: am654: Add support for boot device detection

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: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm: K3: Update _start instruction

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: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

arm: K3: Add support for AM654 SoC definition

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: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm: K3: Add initial support for TI's K3 generation of SoCs

Add support for Texas Instruments' K3 Generation Processor
families.

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

ARM: uniphier: remove ad-hoc clock enabling for EHCI

The MIO clock is enabled by default, and the STDMAC clock is
enabled by the clk driver.  The ad-hoc way to enable the clock
is no longer needed.

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

mmc: uniphier-sd: sync with Linux

Sync with the driver code and the binding recently merged in Linux.

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

ARM: uniphier: enable CONFIG_CMD_UBI

Now that CONFIG_SYS_MONITOR_LEN increased, we have room for enabling
more options again.

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

ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN again

With the migration to distro-boot, the size of the U-Boot proper
image for uniphier_v7_defconfig exceeded the current limit, 576KB.
Increase it to 832KB.

CONFIG_SYS_UBOOT_BASE must be moved as well to avoid the image
over-wrap because the boot ROM of Pro4, Pro5, PXs2/LD6b loads
the SPL to the physical address 0x100000.

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

ARM: dts: uniphier: sync DT with Linux 4.19-rc1

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

MAINTAINERS: Add myself as the FPGA maintainer

FPGA subsystem requires special care that's why it should be maintained
via one tree.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Fix loads command

Convert last loads command to fpga subcommands.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Use CMD_RET_FAILURE instead of simple 1

Use standard return command failure macro.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Add support for missing fpga loadmk commands

There are ways how to call fpga loadmk

1. Full command
fpga loadmk [dev] [address]

2. Dev setup via variable
set fpga [dev]
fpga loadmk [address]

3. Address setup via variable
set fpgadata [address]
fpga loadmk [dev]

4. Dev and address setup via variables
set fpga [dev]
set fpgadata [address]
fpga loadmk

Before this patch only cases 1 and 3 are working but the part of code
was trying to support also cases 2 and 4.
This patch is adding support for cases 2 and 4 to have all of
combinations supported.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Fix loadmk command

Convert loadmk command to fpga subcommands. Not all combinations are
working but they have never worked properly. This will be fixed later.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Fix loadfs command

Convert loadfs command to fpga subcommands.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Fix dump and all direct fpga load commands

Separate dump, load, loadb, loadp and loadbp commands to separate
functions to make it clear how they are called and what parameters they
need.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Extract fpga info command to separate function

Move fpga info to U_BOOT_CMD_MKENT subcommand.
Also use strtol instead of simple_strtoul. The reason is that if -1 is
passed (or fpga info without "fpga" variable) the list of all fpgas is
shown.
This functionality is in the fpga core but it couldn't be performed.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Create new do_fpga_wrapper for using u-boot subcommands

Create command wrapper to clean fpga subcommands.
The function logic is taken from cmd_dm.c

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Clean wrong_parms handling

There is no reason to check parameters in separate switch. Check them
directly when they are read. Also there is no reason to check loadmk
case separately because fpga_data address must be non zero too.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Remove parameter checking from fpga loadfs command

Parameter checking is dead code because all the time there must be all
params assigned. If they are not assigned there is no 9th parameters
passed and checking before return CMD_RET_USAGE.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Move parameter checking for loadfs/loads

There is no reason to check parameters in separate switch before main
one. This patch is simplifying error path and checking parameters right
after assignment.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Cleanup error handling in connection to FPGA_NONE

Incorrect command is already handled and FPGA_NONE should be used only
one. In case of error CMD_RET_USAGE can be returned directly without any
addition logic around.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Move fpga_get_op to avoid local function declaration

Move fpga_get_op() to top of file to remove local function declaration
and also remove useless retyping.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Move error handling to do_fpga()

Clean fpga_get_op() error handling by moving checking/print to do_fpga.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

test/py: Extend fpga command to test all fpga load types

Add support for info, load, loadp, loadb, loadbp, loadmk_legacy,
loadmk_legacy_gz, loadmk_fit, loadfs also with variable support.

There are probably missing failed tests.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fpga: Remove fit image support passed without fpga device

The patch applied in 2010
"cmd_fpga: cleanup help and check parameters"
(sha1: a790b5b2326be9d7c9ad9e3d9b51a8bfabc62d07"
was adding this checking

+       if (dev == FPGA_INVALID_DEVICE) {
+               puts("FPGA device not specified\n");
+               op = FPGA_NONE;
+       }

which simply broke one command flow which was
setenv fpga <dev>
fpga loadmk <addr> // legacy image
fpga loadmk <addr>:<fit_image_name> //fit image

Also this sequence for FIT image is completely broken
setenv fpga <dev>
setenv fpgadata <addr>:<fit_image_name>
fpga loadmk
(Note: For legacy images this is working fine).

even from code I don't think this has ever worked properly
for fit image (dev = FPGA_INVALID_DEVICE should be rejected
by fpga core). Fit image support was in 2008 added by:
"[new uImage] Add new uImage fromat support to fpga command"
(sha1: c28c4d193dbfb20b2dd3a5447640fd6de7fd0720)

Just a summary of these facts that none found this for pretty long time
it shouldn't be a problem to remove this flow (without fpga dev)
completely to simplify the code.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

fpga: Kconfig: Replace spaces with tabs

Trivial Kconfig cleanup. Use tabs instead of spaces.

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

cmd: part: use MAX_SEARCH_PARTITIONS for part search

Use Macro instead of hard code.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

arm: armv7m: clean up armv7m unified code compilation

unified syntax should be selected by config ARM_ASM_UNIFIED

Signed-off-by: Vikas Manocha <vikas.manocha@st.com>

arm: armv7m: remove un-necessary If then instruction

With gas option -mimplicit-it=always, IT block is inserted by the assembler
for thumb2.

Signed-off-by: Vikas Manocha <vikas.manocha@st.com>

arm: stm32: Remove redundant thumb build selection

All armv7m arch builds are thumb & SYS_THUMB_BUILD is already selected by
CPU_ARMV7M.

Signed-off-by: Vikas Manocha <vikas.manocha@st.com>

arm: spear: enable GPIO3 and 4 clocks when the GPIO controller driver is built

There are multiple GPIOs that can be used with the same driver depending
on the CONFIG_GPIO_BASE defined in the controller driver.

GPIO3 and 4 require a clock to be enabled so let's enable them when the
driver is built.

Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>

tools: mkimage: Ensure munmap unmaps the same length that was mapped

The set_header call in kwbimage.c adds a checksum to the end of the
image in addition to setting up the header. It 'helpfully' updates the
st_size to match the fact that the file is now longer. However, mkimage
uses this length in the munmap call. This can lead to unmapping an extra
page, of perhaps required data. When this happens, a SEGV can occur.

To prevent this from happening, the munmap call now uses the same length
that was passed to mmap. This could also have been fixed by not changing
the length in kwbimage.c, however changing it in the main file means
that other plugins will also not fall for the same trap.

Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
Signed-off-by: Chris Packham <judge.packham@gmail.com>
[cp: resolve checkpatch complaints]
Tested-by: Chris Packham <judge.packham@gmail.com>

serial: omap: Introduce DM specific omap serial

Add driver model support for OMAP_SERIAL while reusing
the functions in ns16550.c

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>

omap3: pandora: Enable DM_SERIAL

This patch enables DM_SERIAL for the pandora board. Verified that
the default kernel can still be booted with this.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>