This fixes SPL linker script size checks for 3 lds files where the size
checks were implemented as "x < YYY_MAX_SIZE".

Fix the size checks to be "x <= YYY_MAX_SIZE" instead.

Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

Select the PL310 UCLASS_CACHE driver for SoCFPGA.

Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>

Find the UCLASS_CACHE driver to configure the cache controller's
settings.

Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>

Add a PL310 cache controller driver that is usually found on
ARMv7(32-bit) devices. The driver configures the cache settings that can
be found in the device tree files.

This initial revision only configures basic settings(data & instruction
prefetch, shared-override, data & tag latency). I believe these are the
settings that affect performance the most. Comprehensive settings can be
done by the OS.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>

The cache UCLASS will be used for configure settings that can be found
in a CPU's L2 cache controller.

Add a uclass and a test for cache.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>

Add the PL310 macros for latency control setup, read and write bits.

Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>

Linux commit 8ecd7f5970c5 ("ARM: 8483/1: Documentation: l2c: Rename
l2cc to l2c2x0")

Linux docs:
Documentation/devicetree/bindings/arm/l2c2x0.txt

Copied from Linux kernel v5.0.

"The documentation in the l2cc.txt is specific to the L2 cache
controllers L2C210/L2C220/L2C310 (also known as PL210/PL220/PL310
and variants) and not generic as the file name implies. It's not
valid for integrated L2 controllers as found in e.g.
Cortex-A15/A7/A57/A53."

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>

AM654 SoC is IO coherent wrt A53 cores, therefore enable
SYS_DISABLE_DCACHE_OPS to avoid cache operations in A53
SPL/U-Boot.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>

On AM654 SoC(arm64) which is IO coherent and has L3 Cache, cache
maintenance operations being done to support non-coherent platforms
causes issues.

For example, here is how U-Boot prepares/handles a buffer to receive
data from a device (DMA Write). This may vary slightly depending on the
driver framework:

	Start DMA to write to destination buffer
	Wait for DMA to be done (dma_receive()/dma_memcpy())
	Invalidate destination buffer (invalidate_dcache_range())
	Read from destination buffer

The invalidate after the DMA is needed in order to read latest data from
memory that’s updated by DMA write. Also, in case random prefetch has
pulled in buffer data during the “wait for DMA” before the DMA has
written to it. This works well for non-coherent architectures.

In case of coherent architecture with L3 cache, DMA write would directly
update L3 cache contents (assuming cacheline is present in L3) without
updating the DDR memory. So invalidate after “wait for DMA” in above
sequence would discard latest data and read will cause stale data to be
fetched from DDR. Therefore invalidate after “wait for DMA” is not
always correct on coherent architecture.

Therefore, provide a Kconfig option to disable cache maintenance ops on
coherent architectures. This has added benefit of improving the
performance of DMA transfers as we no longer need to invalidate/flush
individual cache lines(especially for buffer thats several KBs in size).

In order to facilitate use of same Kconfig across different
architecture, I have added the symbol to top level arch/Kconfig file.
Patch currently disables cache maintenance ops for arm64 only.
flush_dcache_all() and invalidate_dcache_all() are exclusively used
during enabling/disabling dcache and hence are not disabled.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>

If building with SPL_LOAD_FIT_FULL and FIT_SIGNATURE, but without
SPL_FIT_SIGNATURE then the build fails with:

  common/built-in.o: In function `fit_image_verify_with_data':
  common/image-fit.c:1220: undefined reference to `fit_image_verify_required_sigs'
  common/image-fit.c:1244: undefined reference to `fit_image_check_sig'
  common/built-in.o: In function `fit_image_load':
  common/image-fit.c:1857: undefined reference to `fit_config_verify'

Refactor so that host builds still depend on FIT_SIGNATURE, but target
builds check FIT_SIGNATURE/SPL_FIT_SIGNATURE dependent on the build.

Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

- mscc: small fixes, enhance network support for Serval, Luton and Ocelot
- mt7620: rename arch to more generic name mtmips
- mips: pass initrd addresses via DT as physical addresses

- Remove dead code from davinci
- Migrate CONFIG_SUPPORT_EMMC_BOOT

>From way back in 2015:

  commit dffb86e4
  Author: Masahiro Yamada <yamada.masahiro@socionext.com>
  Date:   Wed Aug 12 07:31:54 2015 +0900

    of: flip CONFIG_SPL_DISABLE_OF_CONTROL into CONFIG_SPL_OF_CONTROL

    As we discussed a couple of times, negative CONFIG options make our
    life difficult; CONFIG_SYS_NO_FLASH, CONFIG_SYS_DCACHE_OFF, ...
    and here is another one.

    Now, there are three boards enabling OF_CONTROL on SPL:
     - socfpga_arria5_defconfig
     - socfpga_cyclone5_defconfig
     - socfpga_socrates_defconfig

    This commit adds CONFIG_SPL_OF_CONTROL for them and deletes
    CONFIG_SPL_DISABLE_OF_CONTROL from the other boards to invert
    the logic.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>

This converts the following to Kconfig:
   CONFIG_SUPPORT_EMMC_BOOT

As requested by Michal Simek <michal.simek@xilinx.com>, these boards
have no eMMC so CONFIG_SUPPORT_EMMC_BOOT has not been migrated:

  xilinx_zynqmp_zc1275_revB
  xilinx_zynqmp_zc1751_xm018_dc4
  xilinx_zynqmp_zc1751_xm019_dc5
  xilinx_zynqmp_zcu100_revC
  xilinx_zynqmp_zcu102_rev1_0
  xilinx_zynqmp_zcu102_revA
  xilinx_zynqmp_zcu102_revB
  xilinx_zynqmp_zcu104_revA
  xilinx_zynqmp_zcu104_revC
  xilinx_zynqmp_zcu106_revA
  xilinx_zynqmp_zcu111_revA

Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Patrick Delaunay <patrick.delaunay@st.com>
Acked-by: Ramon Fried <ramon.fried@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>

The support for DaVinci DM* SoCs has been dropped a while ago. There's
still a lot of leftover code in mach-davinci though. Entirely remove
certain files and modify the common code to no longer reference
unsupported chips.

Note: all DaVinci platforms supported in u-boot now define SOC_DA8XX
but not all define SOC_DA850 (e.g. omapl138). We can safely remove
all ifdefs for the former, but let's leave the ones for the latter.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The support for DaVinci DM* SoCs has been dropped. The ifdefs in the
musb_hcd driver are no longer needed. Remove them.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Marek Vasut <marex@denx.de>

The support for DaVinci DM* SoCs has been dropped. The code that used
to be relevant to dm644x is no longer needed. Remove it.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The support for DaVinci DM* boards has been dropped a while ago. The
code for all those PHYs is no longer used and they have their own
proper PHY drivers in drivers/net/phy anyway. Remove all dead code.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The boards with SoCs from the DaVinci DM* family used to come with
different PHYs that needed special support implemented in mach-davinci.

Since the support for these chips has long been removed, we can now
drop this unnused code from the emac driver.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

- Misc MMC, FPGA bridge, general SoCFPGA fixes

- DaVinci updates

- Fix in kwbimage (return code checking) (Young Xiao)
- Misc updates to Turris Omnia (Marek)

There are a few functions defined in the header file, but they are
not referenced by any Davinci code.  In order to make a general
function in the future with static function declarations, this
patch will remove the references all together.

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

There is a delay function that was commented out.  This patch
re-enables it, because it will be needed for da850 ohci support.

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

Update device tree for luton to add support for luton pcb90.
This pcb has 24 ports from which 12 ports are connected to
SerDes6G.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>

Implement method board_phy_config to configure the external phys
on the pcb90.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>

Update Luton network driver to have support also for pcb90. The pcb90
has 24 ports from which 12 ports are connected to SerDes6G.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>

Currently mach-mt7620 contains only support for mt7628. To avoid confusion,
rename mach-mt7620 to mach-mtmips, which means MediaTek MIPS platforms.
MT7620 and MT7628 should be distinguished by SOC_MT7620 and SOC_MT7628
because they do not share the same lowlevel codes.

Dependencies of four drivers are changed to SOC_MT7628 as these drivers
are only used by MT7628.

Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>

Update device tree for ocelot to add support for ocelot pcb120.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>

Implement method board_phy_config to configure the phy for pcb120.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>

Update Ocelot network driver to have support also for pcb120.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>

Microsemi SoC defines CONFIG_SYS_SDRAM_BASE to be 0x80000000, which
represents the start of kseg0 and represents a virtual address. Meaning
that the initrd_start and initrd_end point somewhere kseg0.
When these parameters are passed to linux kernel through DT
they are pointing somewhere in kseg0 which is a virtual address but linux
kernel expects the addresses to be physical addresses(in kuseg) because
it is converting the physical address to a virtual one.

Therefore update the uboot to pass the physical address of initrd_start
and initrd_end by converting them using the function virt_to_phys before
setting up the DT.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

Remove "select MSCC_BITBANG_SPI_GPIO" since Kbuild option was deleted
back in commit ace9c103:

  commit ace9c103
  Author: Lars Povlsen <lars.povlsen@microchip.com>
  Date:   Tue Jan 8 10:38:35 2019 +0100

    mips: gpio: mscc: Obsoleted gpio-mscc-bitbang-spi.c

Update default config to use network driver for Serval SoCs.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>

Add ethernet nodes for Serval SoCs family. There are 2 pcb in this
family: pcb105 and pcb106.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>

In Serval SoC family there are 2 different pcb, both of them have the same
phy, but with different version. Therefore implement board_phy_config
and set all the phys in the same way.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>

Add network driver for Microsemi Ethernet switch.
It is present on Serval SoCs.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

When detecting the board, it was reading a register in the GPIO page of
the phy and based on that value it was making a decision. The bug was that
after the GPIO page for the first phy was set it was not reseted back.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>

In case the ddr training was failing, it couldn't reset, it was just
hanging. Therefore reimplement it, so when ddr training is failing
it would call _machine_restart, which power downs the DDR and does
a force reset.

Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>