Add a driver which supports pin multiplexing setup for the most commonly
used peripherals.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>

PMU is the power management unit and GRF is the general register file. Both
are heavily used in U-Boot. Add header files with register definitions.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>

Add necessary structs to have the driver also work for the serial
on the rk3188.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>

Add the entry for the rk3188 requiring rc4-encryption of the SPL.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Rockchip SoCs allow the spl code to be rc4-encoded, not only the
image header, but only newer SoCs allow this encoding to be disabled.

The rk3188 is not part of those and requires its boot code to be
rc4-encoded with the regular key. So add the ability to do this
encoding via a setting on a per-soc basis when building spl images.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Kever Yang <kever.yang@rock-chips.com>

So far spl-boards have declared the back_to_brom() function as simple
extern in the files themself. That doesn't scale well if every boards
defines this on its own.
Therefore move the declarations to a bootrom header.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Kever Yang <kever.yang@rock-chips.com>

Right now the ROCKCHIP_SPL_BACK_TO_BROM option both triggers
compilation of the bootrom hook-code as well as enabling the
behaviour of loading the full U-Boot via the boot.

New added socs may always need the bootrom code, while still
being able to decide between loading U-Boot regularly or via
the bootrom separately.

So move the compilation of the bootrom code to a hidden option
that gets selected by ROCKCHIP_SPL_BACK_TO_BROM, but can also
be selected by other parts.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>

The sdram IP blocks used on rk3066, rk3188 and rk3288 are very similar
and we want to unify things once all 3 work as expected.
Therefore try to keep the rk3288 sdram driver in line by applying the
general review comments received for the rk3188 variant to it as well.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Simon Glass <sjg@chromium.org>

Use defines to describe the bit shifts used to create the
table for ddrconf register values.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Simon Glass <sjg@chromium.org>

The gpll and cpll init values are only used in rk_clk_init in the SPL
and therefore produce compile time warnings in regular uboot builds.
Fix that with an #ifdef.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Simon Glass <sjg@chromium.org>
Added rockchip tag:
Signed-off-by: Simon Glass <sjg@chromium.org>

Right now the u-boot,dm-pre-reloc flag will make each marked node
always appear in both spl and tpl. But systems needing an additional
tpl might have special constraints for each, like the spl needing to
be very tiny.

So introduce two additional flags to mark nodes for only spl or tpl
environments and introduce a function dm_fdt_pre_reloc to automate
the necessary checks in code instances checking for pre-relocation
flags.

The behaviour of the original flag stays untouched and still marks
a node for both spl and tpl.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Kever Yang <kever.yang@rock-chips.com>

rk3399 has different syscon registers which may used in spl,
add to support rk3399 spl.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Added rockchip tag:
Signed-off-by: Simon Glass <sjg@chromium.org>

Do not use the API which of-platdata not support.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Added rockchip tag:
Signed-off-by: Simon Glass <sjg@chromium.org>

Change some API in order to enable of-platdata.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Added rockchip tag:
Signed-off-by: Simon Glass <sjg@chromium.org>

Add ddr clock setting, add rockchip_get_pmucru API,
and enable of-platdata support.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Added rockchip tag and fix pmuclk_init() build warning:
Signed-off-by: Simon Glass <sjg@chromium.org>

rk3399 grf register bit defenitions should locate in header
file, so that not only pinctrl can use it.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Added rockchip tag:
Signed-off-by: Simon Glass <sjg@chromium.org>

Use spl_early_init() to make sure that early malloc() is initialised. This
fixes booting on firefly-rk3288, for example.

Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Eddie Cai <eddie.cai.linux@gmail.com>

At present malloc_base/_limit/_ptr are not initialised in spl_init() when
we call spl_init() in board_init_f(). This is due to a recent change aimed
at avoiding overwriting the malloc area set up on some boards by
spl_relocate_stack_gd().

However if CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN is not defined, we now
skip setting up the memory area in spl_init() which is obviously wrong.

To fix this, add a new function spl_early_init() which can be called in
board_init_f().

Fixes: b3d2861e (spl: Remove overwrite of relocated malloc limit)
Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
Rewrote spl_{,early_}init() to avoid duplicate code:
Rewrite/expand commit message:
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Eddie Cai <eddie.cai.linux@gmail.com>

At first, the ARM64 Linux booting requirement recommended that the
kernel image be placed text_offset bytes from 2MB aligned base near
the start of usable system RAM because memory below that base address
was unusable at that time.

This requirement was relaxed by Linux commit a7f8de168ace ("arm64:
allow kernel Image to be loaded anywhere in physical memory").
Since then, the bit 3 of the flags field indicates the tolerance
of the kernel physical placement.  If this bit is set, the 2MB
aligned base may be anywhere in physical memory.  For details, see
Documentation/arm64/booting.txt of Linux.

The booti command should be also relaxed.  If the bit 3 is set,
images->ep is respected, and the image is placed at the nearest
bootable location.  Otherwise, it is relocated to the start of the
system RAM to keep the original behavior.

Another wrinkle we need to take care of is the unknown endianness of
text_offset for a kernel older than commit a2c1d73b94ed (i.e. v3.16).
We can detect this based on the image_size field.  If the field is
zero, just use a fixed offset 0x80000.

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

Richard reported U-Boot tools issues in OpenEmbedded/Yocto project.

OE needs to be able to change the default compiler. If we pass in
HOSTCC through the make command, it overwrites all HOSTCC instances,
including ones in tools/Makefile and tools/env/Makefile, which breaks
"make cross_tools" and "make env", respectively.

Add "override" directives to avoid overriding HOSTCC instances that
really need to point to the cross-compiler.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

These two functions are only used in lib/tiny-printf.c .

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Stefan Roese <sr@denx.de>

Leave only detected flash type enabled in FTD as otherwise GPMC CS is
claimed (and never freed) by Linux, causing 'concurent' flash type
not to be probed.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>

ISEE's U-Boot and Linux are using 1bit ECC scheme, while we
switched to 8bit ECC to fullfill flash specification requirements.
However when trying to run U-Boot on board with 1bit ECC'd data
on flash, UBI code takes several minutes to pass scan as reading
of every block ends with ecc error (which is also printed on
console).
So, until proper solution is developed, disable environment
alltogether.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>

This is a 96Board compliant board based on STiH410 SoC:
  - 1GB DDR
  - On-Board USB combo WiFi/Bluetooth RTL8723BU
    with PCB soldered antenna
  - Ethernet 1000-BaseT
  - SATA
  - HDMI
  - 2 x USB2.0 type A
  - 1 x USB2.0 type micro-AB
  - SD card slot
  - High speed connector (SD/I2C/USB interfaces)
  - Low speed connector (UART/I2C/GPIO/SPI/PCM interfaces)

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

This device tree has been extracted from v4.9 kernel

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Add STMicroelectronics STiH410 pinctrl driver

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Add SDHCI host controller found on STMicroelectronics SoCs

On some ST SoCs, i.e. STiH407/STiH410, the MMC devices can live
inside a dedicated flashSS sub-system that provides an extend subset
of registers that can be used to configure the Arasan MMC/SD Host
Controller.

This means, that the SDHCI Arasan Controller can be configured to be
eMMC4.5 or 4.3 spec compliant.

W/o these settings the SDHCI will configure and use the MMC/SD
controller with limited features e.g. PIO mode, no DMA, no HS etc.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

As no gpio.h is defined in arch/arm/include/asm/arch-stih410,
to avoid compilation failure, do not include asm/arch/gpio.h.

This is needed for example when including sdhci.h, which include
asm/gpio.h>.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

This patch adds support to ASC (asynchronous serial controller)
driver, which is basically a standard serial driver. This IP
is common across other STMicroelectronics SoCs

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Add ARM global timer based timer

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The STiH410 is an advanced multi-HD AVC processor with 3D
graphics acceleration and 1.5-GHz ARM Cortex-A9 SMP CPU
part of the STiH407 family.

It has wide connectivity including USB 3.0, PCI-e, SATA
and gigabit ethernet.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>

The SysTick is a 24-bit down counter that is found on all ARM Cortex
M3, M4, M7 devices and is always located at a fixed address.

The number of reference clock ticks that correspond to 10ms is normally
defined in the SysTick Calibration register's TENMS field. However, on some
devices this is wrong, so this driver allows the clock rate to be defined
using CONFIG_SYS_HZ_CLOCK.

Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Reviewed-by: Vikas MANOCHA <vikas.manocha@st.com>

The size field in GP header that is expected by ROM is size of the
image + size of the header. But omapimage generates a gp header
only with size of the image as size field. Fix it

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

The workaround for ARM errata 725233 had been lost since
commit 45bf0585 (armv7: adapt omap3 to the new cache
maintenance framework). Bring it back in order to avoid
very difficult to reproduce, but actually encountered in
the wild CPU deadlocks when running software rendered
X11 desktop on OMAP3530 hardware.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Migrate to Kconfig]
Signed-off-by: Tom Rini <trini@konsulko.com>

Boards with OMAP3530 SoC fail to boot since commit bd2c4522
("ti: armv7: enable EXT support in SPL (using ti_armv7_common.h)")
because it enabled the use of Thumb2 for the SPL.

Experiments have shown that the deadlock happens in the
prcm_init() function from 'arch/arm/mach-omap2/omap3/clock.c'.

This patch enforces the compilation of clock.c source file in
ARM mode and makes the deadlock disappear. We are yet to figure
out the root cause of the problem. Still this is somewhat
better than having non-bootable boards for years.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Borrowing from omap3_logic, switch to SPL_SYS_MALLOC_SIMPLE and moving
the stack to DDR as soon as we're able.

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

For better maintainability.

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

Fix warnings reported when built with W=1, by DTC 1.4.2 or later:
  Node /memory has a reg or ranges property, but no unit name

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

Linux Commit 9c0da3cc61f1 ("ARM: dts: explicitly mark skeleton.dtsi
as deprecated") declared that skeleton.dtsi was deprecated.

Move the memory node below to suppress warnings of FDTGREP.

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