Delete CONFIG_SKIP_LOWLEVEL_INIT define in ls1021atwr.h and
ls1021aqds.h can let it run cpu_init_cp15 to enable i-cache. First
stage of u-boot can run faster after that. There is a description
about skip lowlevel init in board/freescale/ls1021atwr/README.
Signed-off-by: NXiaoliang Yang <xiaoliang.yang@nxp.com>
Reviewed-by: NYork Sun <york.sun@nxp.com>

Update the API's for transition of Security Monitor states. Instead
of providing both initial and final states for transition, just
provide final state for transition as Security Monitor driver will
take care of it internally.
Signed-off-by: NSumit Garg <sumit.garg@nxp.com>
[York Sun: Reformatted commit message slightly]
Reviewed-by: NYork Sun <york.sun@nxp.com>

By default the SATA IP on the ls1043a/ls1046a SoCs does not
generating coherent/snoopable transactions.  This patch enable
it in the SCFG_SNPCNFGCR register along with sata axicc register.
In addition, the dma-coherent property must be set on the SATA
controller nodes.
Signed-off-by: NTang Yuantian <yuantian.tang@nxp.com>
[York Sun: Reformatted commit message]
Reviewed-by: NYork Sun <york.sun@nxp.com>

The default values for Port Phy2Cfg register and
Port Phy3Cfg register are better, no need to overwrite them.
Signed-off-by: NTang Yuantian <yuantian.tang@nxp.com>
Reviewed-by: NYork Sun <york.sun@nxp.com>

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

Authentication of images in Falcon Mode is not supported. Do not enable
SPL_OS_BOOT when TI_SECURE_DEVICE is enabled. This prevents attempting
to directly load kernel images which will fail, for security reasons,
on HS devices, the board is locked if a non-authenticatable image load
is attempted, so we disable attempting Falcon Mode.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Acked-by: NLokesh Vutla <lokeshvutla@ti.com>

This config option seems to be unused and is probably vestigial.
Remove it.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Acked-by: NLokesh Vutla <lokeshvutla@ti.com>

Like OMAP54xx and AM43xx family SoCs, AM33xx based SoCs have high
security enabled models. Allow AM33xx devices to be built with
HS Device Type Support.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Acked-by: NLokesh Vutla <lokeshvutla@ti.com>

When CONFIG_FIT_IMAGE_POST_PROCESS or CONFIG_SPL_FIT_IMAGE_POST_PROCESS
is enabled board_fit_image_post_process will be called, add this
function to am33xx boards when CONFIG_TI_SECURE_DEVICE is set to
verify the loaded image.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Acked-by: NLokesh Vutla <lokeshvutla@ti.com>

The option SPL_SPI_SUPPORT is used to enable support in SPL for loading
images from SPI flash, it should not be used to determine the build type
of the SPL image itself. The ability to read images from SPI flash does
not imply the SPL will be booted from SPI flash.

Unconditionally build SPI flash compatible SPL images.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Acked-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Add a section describing the additional boot types used on AM33xx
secure devices.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Acked-by: NLokesh Vutla <lokeshvutla@ti.com>

Depending on the boot media, different images are needed
for secure devices. The build generates u-boot*_HS_* files
as appropriate for the different boot modes.

For AM33xx devices additional image types are needed for
various SPL boot modes as the ROM checks for the name of
the boot mode in the file it loads.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>
Acked-by: NLokesh Vutla <lokeshvutla@ti.com>

The config option AM33XX is used in several boards and should be
defined as a stand-alone option for this SOC. We break this out
from target boards that use this SoC and common headers then enable
AM33XX on in all the boards that used these targets to eliminate any
functional change with this patch.

This is similar to what has already been done in
9de852642cae ("arm: Kconfig: Add support for AM43xx SoC specific Kconfig")
and is done for the same reasons.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Acked-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Adds a secure dram reservation fixup for secure
devices, when a region in the emif has been set aside
for secure world use. The size is defined by the
CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE config option.
Signed-off-by: NDaniel Allred <d-allred@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

If the ending portion of the DRAM is reserved for secure
world use, then u-boot cannot use this memory for its relocation
purposes. To prevent issues, we mark this memory as PRAM and this
prevents it from being used by u-boot at all.
Signed-off-by: NDaniel Allred <d-allred@ti.com>

After EMIF DRAM is configured, but before it is used,
calls are made on secure devices to reserve any configured
memory region needed by the secure world and then to lock the
EMIF firewall configuration. If any other firewall
configuration needs to be applied, it must happen before the
lock call.
Signed-off-by: NDaniel Allred <d-allred@ti.com>

Create a few public APIs which rely on secure world ROM/HAL
APIs for their implementation. These are intended to be used
to reserve a portion of the EMIF memory and configure hardware
firewalls around that region to prevent public code from
manipulating or interfering with that memory.
Signed-off-by: NDaniel Allred <d-allred@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Adds start address and size config options for setting aside
a portion of the EMIF memory space for usage by security software
(like a secure OS/TEE). There are two sizes, a total size and a
protected size. The region is divided into protected (secure) and
unprotected (public) regions, that are contiguous and start at the
start address given. If the start address is zero, the intention
is that the region will be automatically placed at the end of the
available external DRAM space.
Signed-off-by: NDaniel Allred <d-allred@ti.com>

rockchip platform have a protocol to pass the the kernel reboot mode to bootloader
by some special registers when system reboot. In bootloader we should read it and take action.

We can only setup boot_mode in board_late_init becasue "setenv" need env setuped.
So add CONFIG_BOARD_LATE_INIT to common header and use a entry "rk_board_late_init"
to replace "board_late_init" in board file.
Signed-off-by: NJacob Chen <jacob2.chen@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

To keep it same with 3288
Signed-off-by: NJacob Chen <jacob2.chen@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Signed-off-by: NJacob Chen <jacob2.chen@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

To keep it same with 3288.
Signed-off-by: NJacob Chen <jacob2.chen@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The latest rk3288-miniarm board doesn't have eMMC device, so remove it.
Signed-off-by: NZiyuan Xu <xzy.xu@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Enable the pwm regulator for evb-rk3399.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Add a regulator-init-microvolt for vdd_center regulator
so that we can get a init value for driver probe.
Not like pmic regulator, the PWM regulator do not have a
known default output value, so we would like to init the
regulator when driver probe.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Enable DM_PWM and DM_REGULATOR on rockchip SoCs.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Add vdd_center pwm regulator get_device to
enable this regulator.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

add driver support for pwm regulator.
Signed-off-by: NElaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Reference to kernel source code, rockchip pwm has three
type, we are using v2 for rk3288 and rk3399, so let's
update the register to sync with pwm_data_v2 in kernel.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Update PPLL to 676MHz and PMU_PCLK to 48MHz, because:
1. 48MHz can make sure the pwm can get exact 50% duty ratio, but 99MHz
can not,
2. We think 48MHz is fast enough for pmu pclk and it is lower power cost
than 99MHz,
3. PPLL 676 MHz and PMU_PCLK 48MHz are the clock rate we are using
internally for kernel,it suppose not to change the bus clock like pmu_pclk
in kernel, so we want to change it in uboot.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Enable ums feature for rk3036 boards, so that we can mount the mmc
device to PC.
Signed-off-by: Njacob2.chen <jacob2.chen@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Rock2 has been tested with back to brom feature. The tricky part is that
with this feature the default environment is inside u-boot, and it's
defined for every rk3288 board independetly. So I just changed it for
rock2 here if ROCKCHIP_SPL_BACK_TO_BROM.

Solve by moving environment after u-boot before 1M boundary
Signed-off-by: NSandy Patterson <apatterson@sightlogix.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Default SPL_MMC_SUPPORT to false when ROCKCHIP_SPL_BACK_TO_BROM is enabled.
Acked-by: NZiyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: NSandy Patterson <apatterson@sightlogix.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Move back_to_bootrom() call later in SPL init so that the console is
initialized and printouts happen.

Currently when ROCKCHIP_SPL_BACK_TO_BROM is enabled there is no console
output from the SPL init stages.

I wasn't sure exactly where this should happen, so if we are set to do
run spl_board_init, then go back to bootrom there after
preloader_console_init(). Otherwise fall back to old behavior of doing
it in board_init_f.
Signed-off-by: NSandy Patterson <apatterson@sightlogix.com>
Acked-by: NZiyuan Xu <xzy.xu@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The all current Rockchip SoCs supporting 4GB of ram have problems
accessing the memory region 0xfe000000~0xff000000. Actually, some IP
controller can't address to, so let's limit the available range.

This patch fixes a bug which found in miniarm-rk3288-4GB board. The
U-Boot was relocated to 0xfef72000, and .bss variants was also
relocated, such as do_fat_read_at_block. Once eMMC controller transfer
data to do_fat_read_at_block via DMA, DMAC can't access more than
0xfe000000. So that DMAC didn't work sane.
Signed-off-by: NZiyuan Xu <xzy.xu@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>
Tested-by: NSimon Glass <sjg@chromium.org>

when using tftp on the smartweb board, it prints a lot of

CACHE: Misaligned operation at range [23b2e000, 23b2e100]

warnings ... fixed them.
Signed-off-by: NHeiko Schocher <hs@denx.de>

As boot monitor contains a mkimage header, it can be loaded at any location.
So, have a common addr_mon address across all keystone2 SoCs. And also
making sure that boot monitor is installed early during default boot to
avoid any overlapping with other images.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Given that boot monitor image is being generated to a specific target location
depending on the SoC and U-boot relies on addr_mon env variable to be aligned
with boot monitor target location. When ever the target address gets updated in
boot monitor, it is difficult to sync between u-boot and boot monitor and also
there is no way to update user that boot monitor image is updated.

To avoid this problem, boot monitor image is being generated with mkimage
header. Adding support in mon_install command for parsing this header.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

On K2G, the PCIe SerDes h/w is a re-use from other K2 devices and SerDes
driver requires a firmware image to initialize the SerDes h/w device.
This is firmware is part of the initramfs file that is loaded to memory
in u-boot and passed to kernel as in other K2 platforms. This patch
customize the u-boot env to have this done automatically when the K2G EVM
boots up. With this, a user may be able to boot the EVM with a standard
PCIe card at the x1 PCIe slot and release image and test PCIe devices
such as NIC, SATA etc.
Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>