Sort rk3288 boards in alphabetical order.
Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
Reviewed-by: NEddie Cai <eddie.cai.linux@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The (shared) rk3399.dtsi had defined the 'rockchip,vbus-gpio'
properties for each USB 3.0 controller.

As the GPIO usage will vary (e.g. one of those GPIOs shuts down one of
the regulators on the RK3399-Q7) between boards, we move this from the
shared dtsi into the device tree file for the EVB board which these
GPIO definitions match.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

This commit adds the baseline defconfig for the RK3399-Q7 (Puma) SoM
(under the name 'puma-rk3399_defconfig') featuring the Rockchip RK3399
in a Qseven compatible module.

This subsumes the following changes:
 * defconfig: rk3399: migrate CONFIG_SPL_LIBCOMMON_SUPPORT/CONFIG_SPL_LIBGENERIC_SUPPORT
 * defconfig: rk3399-puma: add CONFIG_MMC_DW_ROCKCHIP
 * defconfig: rk3399-puma: disable CONFIG_SPL_OF_PLATDATA
 * defconfig: rk3399-puma: don't USE_TINY_PRINTF
 * defconfig: rk3399-puma: set up CONFIG_SYS_BOARD for the RK3399-Q7
 * defconfig: rk3399-puma: enable the multi-image loading via CONFIG_SPL_FIT
 * defconfig: rk3399-puma: SPL should be able to boot from MMC/SD card
 * defconfig: rk3399-puma: enable GMAC support
 * defconfig: rk3399-puma: enable support for SPI and Winbond SPI flash
 * defconfig: rk3399-puma: enable SPI as a boot-source in SPL
 * defconfig: rk3399-puma: disallow non-FIT images from being loaded
 * defconfig: rk3399-puma: rename to puma-rk3399
 * rockchip: config: rk3399: update defconfigs and rk3399_common

For the RK3399-Q7, we want a default boot-order of SPI -> MMC -> uSD.
This both follows how the BootROM probes devices and is a sane default
for customers in device-personalisation (e.g. it allows for quick and
easy factory programming of unpersonalised devices using an SD card)
and field usage (with customer devices expected to have their firmware
either in SPI or MMC).

However, when probing multiple interfaces (according to the result
from the board_boot_order function), we need to ensure that only valid
FIT images are considered and disable the fallback to assuming that a
raw (binary-only) U-Boot image is loaded (to avoid hangs/crashes from
jumping to random content loaded from devices that are probed, but
don't contain valid image content).

By disabling the SPL_RAW_IMAGE_SUPPORT and SPL_LEGACY_IMAGE_SUPPORT
options, we ensure that raw images (indistinguishable from random
data) are not considered for booting.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>
Drop CONFIG_DEBUG_UART_BOARD_INIT:
Signed-off-by: NSimon Glass <sjg@chromium.org>

The RK3399-Q7 is a system-on-module featuring the Rockchip RK3399
in a Qseven-compatible form-factor.

These changes add a device-tree describing the board and its
interfaces for basic functionality (e.g. GbE, SPI, eMMC, SD-card).

This includes the following changes from the original development:

 * dts: rk3399-puma: include DTS for RK3399-Q7 SoM in the Makefile
 * dts: rk3399-puma: add gmac for the RK3399-Q7

This change enables the Gigabit Ethernet support on the RK3399-Q7.

 * dts: rk3399-puma: use serial0 for stdout
 * dts: rk3399-puma: prepare the sdmmc node for SPL booting
 * dts: rk3399-puma: enable spi1 and spi5, add /spi1/spiflash

The RK3399-Q7 (Puma) unsually (this is a build-time option for
customised boards) has an on-module SPI-flash connected to SPI1.
As of today, this is a Winbond W25Q32DW (32MBit) device.

The SPI5 controller is routed to the Q7 edge connector and provides
general-purpose SPI connectivity for customer base-boards.

With some minor improvements on integration into our outbound tree
 - explicitly modelled the SPI flash as 'spiflash' under spi0
   [dts: rk3399-puma: explicitly model spi-flash under spi1]
 - renamed the aliases to spi0 and spi1 to allow easier use of
   commands and legacy (SPL) infrastructure... i.e. the controllers
   will be 0 and 1 for 'sf probe', 'sspi', etc.
   [dts: rk3399-puma: rename aliases to number spi as 0 and 1 for commands]

 * dts: rk3399-puma: include SPI in the spl-boot-order property
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

On the RK3399-Q7 we need to enable a number of configuration options
(e.g. CONFIG_SPI_FLASH_WINBND) dependent on Kconfig seeing CONFIG_SPI
and CONFIG_SPI_FLASH active.

To allow for these being defined in Kconfig (e.g. via defconfig) and
to avoid a warning on having the macro defined multiple times, we
remove them from the common header file.

Note that the rk3399-evb does not currently have the rk_spi.c driver
active (i.e. CONFIG_ROCKCHIP_SPI), so there's no change to the
evb-rk3399_defconfig as part of this change.

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

For the initial validation of the RK3399-Q7 (Puma), the DDR3 has been
clocked at 666MHz (i.e. DDR3-1333) using the same (safe) settings as
used in Rockchip's MiniLoader.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The RK3399 does not have any boot selection pins and the BootROM probes
the boot interfaces using the following boot-order:
    1. SPI
    2. eMMC (sdhci in DTS)
    3. SD card (sdmmc in DTS)
    4. USB loader
For ease of deployment, the SPL stage should mirror the boot order of
the ROM and use the same probing order (assuming that valid images can
be detected by SPL) unless instructed otherwise.  The boot-order can
then be configured via the 'u-boot,spl-boot-order' property in the
chosen-node of the DTS.

While this approach is easily extensible to other boards, it is only
implemented for the RK3399 for now, as the large SRAM on the RK3399
makes this easy to fit the needed infrastructure into SPL and our
production setup already runs with DM, OF_CONTROL and BLK in SPL.

The new boot-order property is expected to be used in conjunction with
FIT images (and all legacy image formats disabled via Kconfig).

A boot-sequence with probing and fallthroughs from SPI via eMMC to SD
card (i.e. &spiflash, &sdhci, &sdmmc) has been validated on the RK3399-Q7.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: NKlaus Goger <klaus.goger@theobroma-systems.com>
Tested-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The Rock is a RK3188 based single board computer by Radxa.
Currently it still relies on the proprietary DDR init and
cannot use the generic SPL, but at least is able to boot
a linux kernel and system up to a regular login prompt.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>
Fix sort order in defconfig, enable CONFIG_SPL_TINY_MEMSET:
Signed-off-by: NSimon Glass <sjg@chromium.org>

Most of the time the optimised memset() is what we want. For extreme
situations such as TPL it may be too large. For example on the 'rock'
board, using a simple loop saves a useful 48 bytes. With gcc 4.9 and
the rodata bug, this patch is enough to reduce the TPL image below the
limit.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>

At present we sometimes see the following build error when building on a
machine with multiple cores.

+make[2]: *** No rule to make target 'dts/dt.dtb', needed by 'tpl/u-boot-tpl.dtb'.  Stop.

Add a dependency to correct this.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>

firefly have a usb host. add dts node to provide power supply
Signed-off-by: NEddie Cai <eddie.cai.linux@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Commit 3a649407 ("arm: Migrate SYS_THUMB_BUILD to Kconfig, introduce
SPL_SYS_THUMB_BUILD") moved the THUMB_BUILD symbols from the header to
Kconfig symbols. With it still defined in the rk3188 header we end up
with a duplicate symbol and compile errors, so fix that.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NSimon Glass <sjg@chromium.org>

The clock driver for the RK3399 mistakenly used (24 * 2^20) where it
should have used (24 * 10^6) in a few calculations.

This commits fixes this.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

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.