This change adds the gmac node (i.e. the GMAC Ethernet controller) as
defined in the Linux DTS.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The GMAC in the RK3399 is very similar to the RK3288 variant (i.e. it
is a Designware GMAC core and requires similar configuration as the
RK3288 to switch it to RGMII and set up the TX/RX delays for Gigabit).
The key difference is that the register offsets (within the GRF block)
and bit-offsets (within those registers) used to hold the configuration
differ between the various RK32/33 CPUs.

This change refactors the gmac_rockchip.c driver to use a function
table (selected via driver_data) to factor out these differences. Each
function's implementation then matches the underlying processor.

Some collateral changes are needed in the definitions describing the
bits and offsets in the GRF are needed to prefix each set of symbolic
constants with the SoC name to avoid name clashes... and in doing so,
the shifts for masks and constants have been moved into the header
files for readability (and to make it easier to stay below 80 chars).

X-AffectedPlatforms: RK3399-Q7
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: NKlaus Goger <klaus.goger@theobroma-systems.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>
Acked-by: NSimon Glass <sjg@chromium.org>
Fixed commit message typo s/factor our/factor out/:
Signed-off-by: NSimon Glass <sjg@chromium.org>

The Ethernet driver for the RK3288/3399 GMAC makes sure that the clock
is ungated through a call to clk_set_rate(...). Even though nothing
needs to be done on the RK3399 (the clock gates are open and the clock
is external), we need to implement enough support to at least return
success to enable driver probing.

X-AffectedPlatforms: RK3399-Q7
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Due to differences in the code paths for SPL and non-SPL, some static
constant structures remain unused in each build variant. This raises
warnings with recent GCC versions (we currently use GCC-6.3).

The warnings addressed in this commit (by matching #if conditions for
the variable definition with their uses) are:

* for the SPL build:
    drivers/clk/rockchip/clk_rk3399.c:53:29: warning: 'cpll_init_cfg' defined but not used [-Wunused-const-variable=]
     static const struct pll_div cpll_init_cfg = PLL_DIVISORS(CPLL_HZ, 1, 2, 2);
                                 ^~~~~~~~~~~~~
    drivers/clk/rockchip/clk_rk3399.c:52:29: warning: 'gpll_init_cfg' defined but not used [-Wunused-const-variable=]
     static const struct pll_div gpll_init_cfg = PLL_DIVISORS(GPLL_HZ, 2, 2, 1);
                                 ^~~~~~~~~~~~~
* for the non-SPL build:
    drivers/clk/rockchip/clk_rk3399.c:54:29: warning: 'ppll_init_cfg' defined but not used [-Wunused-const-variable=]
     static const struct pll_div ppll_init_cfg = PLL_DIVISORS(PPLL_HZ, 2, 2, 1);
                                 ^~~~~~~~~~~~~
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

To add GMAC (Gigabit Ethernet) support (limited to RGMII only at this
point), we need support for additional pin-configuration.  This commit
adds the pinctrl support for GMAC in RGMII signalling mode:
 * adds a PERIPH_ID_GMAC and the mapping from IRQ number to PERIPH_ID
 * adds the required defines (in the GRF support) for configuring the
   GPIOC pins for RGMII
 * configures the RGMII pins (in GPIOC) when requested via pinctrl

X-AffectedPlatforms: RK3399-Q7
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

An earlier upstream change contained an unconditional debug message
which would show up as a message similar to the following in the
U-Boot startup (after the ATF and before the U-Boot banner):
      time 159f019, 0

This commit removes this message (instead of making if conditional on
being a debug-build), as it doesn't pertain to any initialisation done
in this file.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The BootROM of the RK3399 SoC does not initialise the cntfrq_el0 (which
holds the value 0 (zero) on entry into the SPL. This causes the timebase
for U-Boot not to advance (and will cause a hang where a timeout would
be expected... e.g. if something goes wrong during MMC/SD card startup).

This change defines COUNTER_FREQUENCY, which is used by the AArch64 init
code in arch/arm/cpu/armv8/start.S to set up cntfrq_el0 (if necessary).
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Designware HDMI controller and phy are used in other SoCs as well. Split
out platform independent code.

DW HDMI has 8 bit registers but they can be represented as 32 bit
registers as well. Add support to select access mode.

EDID reading code use reading by blocks which is not supported by other
SoCs in general. Make it more general using byte by byte approach, which
is also used in Linux driver.

Finally, not all DW HDMI controllers are accompanied with DW HDMI phy.
Support custom phys by making controller code independent from phy code.
Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
Tested-by: NNickey Yang <nickey.yang@rock-chips.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The Cortex-A9 socs rk3066 and rk3188 share the IP but have their own
compatible values, so add them to make the i2c on these platforms accessible.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NSimon Glass <sjg@chromium.org>

The armclk starts in slow mode (24MHz) on the rk3188, which results in U-Boot
startup taking a lot of time (U-Boot itself, but also the rc4 decoding done
in the bootrom).

With default pmic settings we can always reach a safe frequency of 600MHz
which is also the frequency the proprietary loader left the armclk at,
without needing access to the systems pmic.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NSimon Glass <sjg@chromium.org>

The armclk starts in slow mode (24MHz) on the rk3188, which makes the whole
startup take a lot of time. We therefore want to at least move to the safe
600MHz value we can use with default pmic settings.
This is also the freqency the proprietary sdram-init leaves the cpu at.

For boards that have pmic control later in u-boot, we also add the option
to set the maximum frequency of 1.6GHz, if they so desire.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NSimon Glass <sjg@chromium.org>

In the beginning, we did SPL -> TPL -> U-Boot, but after clarification
of the real ordering swapped SPL and TPL.
It seems some renames were forgotten and may confuse future readers, so
also swap these to reflect the actual ordering.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NSimon Glass <sjg@chromium.org>

There was still a static ram value set in the rk3188-board from the
time where we didn't have actual sdram init code.
Now the sdram init leaves the ram information in SYS_REG2 and we can
decode it similarly to the rk3288.

Right now we have two duplicates of that code, which is still ok and
doesn't really count as common code yet, but if we get a third copy
at some point from a newer soc, we should think about moving that to
a more general position.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NSimon Glass <sjg@chromium.org>

Right now we're setting the wrong value of 0 as base in the ram_info struct,
which is obviously wrong for the rk3188. So instead set the correct value
we already have in CONFIG_SYS_SDRAM_BASE.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NSimon Glass <sjg@chromium.org>

Building sd images for rk3188 requires more steps due to the needed split
into TPL and SPL as loaders. Describe how to build an image for it in a
separate paragraph in the READER.rockchip file.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NKever Yang <kever.yang@rock-chips.com>

Commit c67c8c60 ("board_init.c: Always use memset()") dropped the naive
memset alternative from board_init_f_init_reserve.
So activate CONFIG_TPL_LIBGENERIC for that common memset implementation.
We cannot use the ARCH-specific memset, as that would incur 200bytes of
additional TPL size, space we do not have.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Rockchip spl driver needs using spl_early_init().

Fixes: b3d2861e (spl: Remove overwrite of relocated malloc limit)
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The config options for pinctrl on the RK3188, RK3288, RK3328 and
RK3399 previously showed up in menuconfig with the generic string
descriptor "Rockchip pin control driver" requiring one to look through
the help/full description to identify which chip each menu entry was
for.

This change renames each option with the chip-name in the description
string to make it easy to identify the configuration options in
menuconfig.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>

To simplify the creation of AArch64 SPL images for the RK3399, we
use the ENABLE_ARM_SOC_BOOT0_HOOK option and prepend 4 bytes of
padding at the start of the text section. This makes it easy for
mkimage to rewrite this word with the 'RK33' boot magic.

This change brings logic to calculate the header size and allocate
the header back in sync. For the RK3399 we now limit the header to
before the payload (i.e. the 'header0' and the padding up to the
actual image) and overwrite the first word (inserted by the
boot0-hook for this purpose) with the 'RK33' magic in-place.

X-AffectedPlatforms: RK3399-Q7
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: NKlaus Goger <klaus.goger@theobroma-systems.com>

The SPL binary needs to be prefixed with the boot magic ('RK33' for
the RK3399) on the Rockchip platform and starts execution of the
instruction word following immediately after this boot magic.

This poses a challenge for AArch64 (ARMv8) binaries, as the .text
section would need to start on the odd address, violating natural
alignment (and potentially triggering a fault for any code that
tries to access 64bit values embedded in the .text section).

A quick and easy fix is to have the .text section include the 'RK33'
magic and pad it with a boot0 hook to insert 4 bytes of padding at the
start of the section (with the intention of having mkimage overwrite
this padding with the appropriate boot magic). This avoids having to
modify the linker scripts or more complex logic in mkimage.

X-AffectedPlatforms: RK3399-Q7
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: NKlaus Goger <klaus.goger@theobroma-systems.com>

The RK3399 boot code (running as AArch64) poses a bit of a challenge
for SPL image generation:
 * The BootROM will start execution right after the 4-byte header (at
   the odd instruction word loaded into SRAM at 0xff8c2004, with the
   'RK33' boot magic residing at 0xff8c2000).
 * The default padding (during ELF generation) for AArch64 is 0x0,
   which is an illegal instruction and the .text section needs to be
   naturally aligned (someone might locate a 64bit constant relative
   to the section start and unaligned loads trigger a fault for all
   privileged modes of an ARMv8)... so we can't simply define the
   CONFIG_SPL_TEXT_BASE option to the odd address (0xff8c2004).
 * Finally, we don't want to change the values used for padding of
   the SPL .text section for all ARMv8 targets to the instruction
   word encoding 'nop', as this would affect all padding in this
   section and might hide errors that would otherwise quickly trigger
   an illegal insn exception.

To deal with this situation, we modify the rkimage generation to
 - understand the fact that the RK3399 needs to pad the header to an
   8 byte boundary using an AArch64 'nop'
 - the necessary logic to adjust the header_size (which controls the
   location where the payload is copied into the image) and to insert
   this padding (AArch64 insn words are always little-endian) into
   the image following the 4-byte header magic.

X-AffectedPlatforms: RK3399-Q7
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: NKlaus Goger <klaus.goger@theobroma-systems.com>

The RC4 encoding works on full blocks, but the calculation of the
starting offset and size are needlessly complicated by using a
reference value known to be offset into a block by the size of the
header and then correcting for the (hard-coded) size of the header
(i.e. 4 bytes).

We change this over to use the RK_SPL_HDR_START directly (which is
known to be on a block boundary).

X-AffectedPlatforms: RK3399-Q7
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: NKlaus Goger <klaus.goger@theobroma-systems.com>

we are using mmc alias , so mmc index have been changed.
now mmc dev 0 is emmc and mmc dev 1 is sdmmc.
Signed-off-by: NJacob Chen <jacob2.chen@rock-chips.com>

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

In this patch-set we add support of new AXS103 firmware as well as
troubleshoot unexpected execution by multiple cores simultaneously.

This includes Marvell mvpp2 patches with the ethernet support for the
ARMv8 Armada 7k/8k platforms. The ethernet patches are all acked by Joe
and he is okay with me pushing them via the Marvell tree.

Actually make use of that shiny new CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK.
Signed-off-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: NMarcel Ziswiler <marcel@ziswiler.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

Introduce CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK to disable the external clock
loopback and use the internal one on SDMMC3 as per the SDMMC_VENDOR_MISC_CNTRL_0
register's SDMMC_SPARE1 bits being set to 0xfffd according to the TRM.
Signed-off-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NMarcel Ziswiler <marcel@ziswiler.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

This patch adds board support for the Toradex Apalis TK1 a computer on
module which can be used on different carrier boards.

The module consists of a Tegra TK1 SoC, a PMIC solution, 2 GB of DDR3L
RAM, a bunch of level shifters, an eMMC, a TMP451 temperature sensor
chip, an I210 gigabit Ethernet controller and a SGTL5000 audio codec.
Furthermore, there is a Kinetis MK20DN512 companion micro controller for
analogue, CAN and resistive touch functionality.

For the sake of ease of use we do not distinguish between different
carrier boards for now as the base module features are deemed
sufficient enough for regular booting.

The following functionality is working so far:
- eMMC boot, environment storage and Toradex factory config block
- Gigabit Ethernet
- MMC/SD cards (both MMC1 as well as SD1 slot)
- USB client/host (dual role OTG port as client e.g. for DFU/UMS or host,
  other two ports as host)
Signed-off-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMarcel Ziswiler <marcel@ziswiler.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

Even though we expect only master core to execute U-Boot code
let's make sure even if for some reason slave cores attempt to
execute U-Boot in parallel with master they get halted very early.

If platform wants it may kick-start slave cores before passing control
to say Linux kernel or any other application that want to see all cores
of SMP SoC up and running.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>

In axs103 v1.1 procedure to kick-start slave cores has changed quite a bit
compared t previous implementation.

In particular:
 * We used to have a generic START bit for all cores selected by CORE_SEL
   mask. But now we don't touch CORE_SEL at all because we have a dedicated
   START bit for each core:
     bit 0: Core 0 (master)
     bit 1: Core 1 (slave)
 * Now there's no need to select "manual" mode of core start

Additional challenge for us is how to tell which axs103 firmware we're
dealing with. For now we'll rely on ARC core version which was bumped
from 2.1c to 3.0.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>

 * Rely on default pulse polarity value
 * Don't mess with "multicore" value as it doesn't affect execution

In essence we now do a bare minimal stuff:
 1) Select HS38x2_1 with CORE_SEL=1 bits
 2) Select "manual" core start (via CREG) with START_MODE=0
 3) Generate cpu_start pulse with START=1
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>

Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

This is a preparation work for the support of CONFIG_BLK.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>