As only FIT image is supported now, this patch is to support loading
32-bit uImage, dtb and rootfs separately.
Signed-off-by: NAlison Wang <alison.wang@nxp.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Fixed checkpatch.pl errors/warnings in board/mpl/common/pci.c
Signed-off-by: NChakra Divi <chakra@openedev.com>

Like commit 3337e3af this enables suitable commands needed for booting
general purpose Linux distribution. This is required for example if we want
to use PXE or DHCP as default boot targets, symbols no longer enabled by
config_distro_defaults.h.
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>

Update the board pinmux for AM572x-evm using latest PMT[1] and the
board files named am572x_gp_evm_A3a_sr2p0 and am572x_gp_evm_A2b_sr1p1
that were autogenerated on 30th January, 2017 by
"Ahmad Rashed <a-rashed@ti.com>" and "Tom Johnson <thjohnson@ti.com>".
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Update the board pinmux for AM571x-IDK board using latest PMT[1] and the
board files named am571x_idk_v1p3b_sr2p0 that were autogenerated on
23rd March, 2017 by "Ahmad Rashed <a-rashed@ti.com>" and
"Tom Johnson <thjohnson@ti.com>".

[1] https://dev.ti.com/pinmux/app.html#/default/Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Update the board pinmux for AM572x-IDK board using latest PMT[1] and the
board files named am572x_idk_v1p3b_sr2p0 that were autogenerated on
30th January, 2017 by "Ahmad Rashed <a-rashed@ti.com>" and
"Tom Johnson <thjohnson@ti.com>".

[1] https://dev.ti.com/pinmux/app.html#/default/Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Add poweroff description to Kconfig to make it selectable
via menuconfig.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Disable D-Cache is required when booting nommu Linux kernel.
(please see Linux kernel source "arch/arm/kernel/head-nommu.S")

U-Boot is enabled D-cache and I-Cache at startup.
However, it does not disable D-Cache before
booting nommu Linux kernel.
Therefore, I call dcache_disable()
when the CPU is ARMv7M to fix this problem.
Signed-off-by: NToshifumi NISHINAGA <tnishinaga.dev@gmail.com>

Refactor OMAP3/4/5 code so that we have only one get_device_type()
function for all platforms.

Details:
 - Add ctrl variable for AM33xx and OMAP3 platforms (like it's done for
   OMAP4/5), so we can obtain status register in common way
 - For now ctrl structure for AM33xx/OMAP3 contains only status register
   address
 - Run hw_data_init() in order to assign ctrl to proper structure
 - Remove DEVICE_MASK and DEVICE_GP definitions as they are not used
   (DEVICE_TYPE_MASK and GP_DEVICE are used instead)
 - Guard structs in omap_common.h with #ifdefs, because otherwise
   including omap_common.h on non-omap4/5 board files breaks compilation

Buildman script was run for all OMAP boards. Result output:
    arm: (for 38/616 boards)
        all +352.5
        bss -1.4
        data +3.5
        rodata +300.0
        spl/u-boot-spl:all +284.7
        spl/u-boot-spl:data +2.2
        spl/u-boot-spl:rodata +252.0
        spl/u-boot-spl:text +30.5
        text +50.4
    (no errors to report)

Tested on AM57x EVM and BeagleBoard xM.
Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>
[trini: Rework the guards as to not break TI81xx]
Signed-off-by: NTom Rini <trini@konsulko.com>

Almost all users of CONFIG_AM33XX/AM43XX have been migrated.  Finish
moving the last few over to Kconfig, and put all of the boards under the
appropriate Kconfig chocie now.  This board choice is non-optional, so
remove that keyword on am33xx.
Signed-off-by: NTom Rini <trini@konsulko.com>

As per the datasheet[1] available for DDR2 part on board
the OMAP-L138 LCDK, the tXSNR (exit self refresh to a
non-read command) is 137.5 ns. This corresponds to a
value of 20 to be written to T_XSNR register field of
OMAP-L138's DDR configuration. The DDR2 is at 150 MHz.

Fix this. The correct value also appears on the initialization
scripts (called CCS GEL files) available on TI's wiki pages[2]

[1] http://www.samsung.com/global/business/semiconductor/file/product/ds_k4t1gxx4qf_rev12-0.pdf
[2] http://processors.wiki.ti.com/index.php/L138/C6748_Development_Kit_(LCDK)#CCS_XML_.26_GEL_FilesSigned-off-by: NSekhar Nori <nsekhar@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Rename command ls to fsls as its conflicting with
generic file systesm command ls and this is causing
compilation failure as below, if both are enabled
and this patch fixes it.

cmd/jffs2.o:(.u_boot_list_2_cmd_2_ls+0x0):
multiple definition of `_u_boot_list_2_cmd_2_ls'
cmd/fs.o:(.u_boot_list_2_cmd_2_ls+0x0):first defined here
scripts/Makefile.build:359: recipe for target 'cmd/built-in.o'
failed
make[1]: *** [cmd/built-in.o] Error 1
Signed-off-by: NSiva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

There is some inconsistency between uses of CONFIG_RTC_DS13xx and
CONFIG_SYS_RTC_DS13xx. Address this by dropping the "SYS" from
these variables.
Signed-off-by: NChris Packham <judge.packham@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

With xip booting configuration, we don't need to copy the next image
(U-Boot or linux xipimage) from flash to sdram area.

Flash memory organization is like this:
	spl-U-Boot:	u-boot-spl.bin 	: 0x0800_0000
	U-Boot :	u-boot-dtb.bin	: 0x0800_8000
	linux :		xipImage	: 0x0800_8000

It is also possible to have U-Boot binary & linux binaries configured at
different addresses of flash memory like U-Boot at 0x0800_8000 & linux
xipImage at 0x0800_4000. But in any case, spl-U-Boot needs to be compiled for
U-Boot as next binary with SPL_OS_BOOT option disabled.
By default, spl is configured to boot linux xipImage.
Signed-off-by: NVikas Manocha <vikas.manocha@st.com>

Signed-off-by: NVikas Manocha <vikas.manocha@st.com>

With overrun enabled, serial port console freezes & stops receiving data with
overun error if we keep sending data.
Signed-off-by: NVikas Manocha <vikas.manocha@st.com>

Enable support for XIP (execute in place) of U-Boot or kernel image. There is
no need to copy image from flash to ram if flash supports execute in place.
Signed-off-by: NVikas Manocha <vikas.manocha@st.com>
Reviewed-by: NAlexandru Gagniuc <alex.g@adaptrum.com>

This commit supports booting from stm32 internal nor flash. spl U-Boot
initializes the sdram memory, copies next image (e.g. standard U-Boot)
to sdram & then jumps to entry point.

Here are the flash memory addresses for U-Boot-spl & standard U-Boot:
	- spl U-Boot		: 0x0800_0000
	- standard U-Boot	: 0x0800_8000

To compile u-boot without spl: Remove SUPPORT_SPL configuration
(arch/arm/mach-stm32/Kconfig)
Signed-off-by: NVikas Manocha <vikas.manocha@st.com>
[trini: Rework Kconfig logic a bit]
Signed-off-by: NTom Rini <trini@konsulko.com>

Signed-off-by: NVikas Manocha <vikas.manocha@st.com>

On ARM v7M, the processor will return to ARM mode when executing blx
instruction with bit 0 of the address == 0. Always set it to 1 to stay in thumb
mode.

At present, it is applied only for raw U-Boot. This patch moves it to just
before booting next image. This way armv7m will be in thumb mode for any image
like raw or image with header like zImage or standard U-Boot.
Signed-off-by: NVikas Manocha <vikas.manocha@st.com>

Here is additional rk3368 and rk3399 support, rv1108 support,
refactoring HDMI video (brought in from Anatolij's tree to resolve
conflicts), some mkimage fixes and a few other things.

With video output support for the RK3399-Q7 (Puma) available, we want
CMD_BMP enabled and the support for 16bit, 24bit and 32bit BMPs
defined.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

Version-changes: 2
- enable SYS_WHITE_ON_BLACK via defconfig
Reviewed-by: NSimon Glass <sjg@chromium.org>

The last set of rebases had dropped the 'grf' field from the common
rk_vop.  Add this back to un-break the build (and driver).
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

This commit enables the RK3399 HDMI TX, which is very similar to the
one found on the RK3288.  As requested by Simon, this splits the HDMI
driver into a SOC-specific portion (rk3399_hdmi.c, rk3288_hdmi.c) and
a common portion (rk_hdmi.c).

Note that the I2C communication for reading the EDID works well with
the default settings, but does not with the alternate settings used on
the RK3288... this configuration aspect is reflected by the driverdata
for the RK3399 driver.

Having some sort of DTS-based configuration for the regulator
dependencies would be nice for the future, but for now we simply use
lists of regulator names (also via driverdata) that we probe.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

To prepare for the addition of RK3399 HDMI support, the HDMI driver is
refactored and broken into a chip-specific and a generic part.  This
change adds the internal interfaces, makes common/reusable functions
externally visible and splits the RK3288 driver into a separate file.

For the probing of regulators, we reuse the infrastructure created
during the VOP refactoring... i.e. we simply call into the helper
function defined for the VOP.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The Linux driver now supports higher mpixelclock settings.
Add these to rockchip_phy_config[] and rockchip_mpll_cfg[].
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This commit adds a driver for the RK3399 VOPs capable and all the
necessary plumbing to feed the HDMI encoder. For the VOP-big, this
correctly tracks the ability to feed 10bit RGB data to the encoder.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

To prepare for adding the RK3399 VOP driver (which shares most of its
registers and config logic with the RK3228 VOP), this change refactors
the driver and splits the RK3288-specific driver off.

The changes in detail are:
- introduces a data-structure for chip-specific drivers to register
  features/callbacks with the common driver: at this time, this is
  limited to a callback for setting the pin polarities (between the
  VOP and the encoder modules) and a flag to signal 10bit RGB
  capability
- refactors the probing of regulators into a helper function that
  can take a list of regulator names to probe and autoset
- moves the priv data-structure into a (common) header file to be
  used by the chip-specific drivers to provide base addresses to
  the common driver
- uses a callback into the chip-specific driver to set pin polarities
  (replacing the direct register accesses previously used)
- splits enabling the output (towards an encoder) into a separate
  help function withint the common driver
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This introduces two new Kconfig options that configure the maximum
allowable framebuffer size (i.e. the memory reservation/allocation for
the framebuffer):
 - VIDEO_ROCKCHIP_MAX_XRES
 - VIDEO_ROCKCHIP_MAX_YRES
The resulting memory allocation will cover 4 byte per pixel for these
resolutions.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

For consistency sake (and as we are about to add new options to this
file), reformat the help for VIDEO_ROCKCHIP.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

For the RK3399-Q7, we need spl_board_init to be called during SPL
startup to set up the pinmux for the debug UART. Enable SPL_BOARD_INIT
via defconfig to ensure this function is in fact called.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

RK3288_TXCLK_DLY_ENA_GMAC_ENABLE, in GRF_SOC_CON3, is supposed to be bit
0xe and not 0xf. Otherwise, it is RGMII RX clock delayline enable and
introduces random delays and data lose.

This commit fixes the issue by replacing RK3288_TXCLK_DLY_ENA_GMAC_ENABLE
with the right shift.
Signed-off-by: NRomain Perier <romain.perier@collabora.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This adds the DDR3-1866 timing via its own DTS and wires it up.  This
(currently) is not the default timing for the RK3399-Q7 and should be
selected explicitly via the config (CONFIG_DEFAULT_DEVICE_TREE).
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

This adds the DDR3-1333 timing via its own DTS and wires it up.  This
is not the default timing for the RK3399-Q7 and should be selected
explicitly via the config (CONFIG_DEFAULT_DEVICE_TREE).
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

To better support different RAM timings (DDR3-1333 and DDR3-1866 are
assembly options for the RK3399-Q7), this refactors the DTS support
and renames the default DTS variant from rk3399-puma to
rk3399-puma-ddr1600:
- changes the rk3399-puma DTS into a board-specific DTSI by removing
  the inclusion of the DRAM timings
- adds a new rk3399-puma-ddr1600.dts, which includes the (new) common
  board DTSI and the DDR3-1600 timing DTSI
- wires this up from arch/arm/dts/Makefile and configs/puma-rk3399_defconfig
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The Linux DTS for the RK3399-Q7 has moved with the times... resync
against it to ensure a consistent configuration.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This commit enables HDMI output in the DTS by adding the necessary
nodes to vopl/vopb and by adding the HDMI node.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The regs_otg field in uintptr_t of the platform data structure for
dwc2-otg has thus far been an unsigned int, but will eventually be
casted into a void*.

This raises the following error with GCC 6.3 and buildman:
  ../drivers/usb/gadget/dwc2_udc_otg.c: In function 'dwc2_udc_probe':
  ../drivers/usb/gadget/dwc2_udc_otg.c:821:8: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
    reg = (struct dwc2_usbotg_reg *)pdata->regs_otg;
          ^

This changes regs_otg to a uintptr_t to ensure that it is large enough
to hold any valid pointer (and fix the associated warning).
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

With HDMI output for the RK3399 working, this update the RK3399-Q7
(Puma) defconfig for the new functionality:
1. enables PMIC command (to check if the HDMI voltages are correct)
      +CONFIG_CMD_PMIC=y
      +CONFIG_CMD_REGULATOR=y
2. enables video-output (via HDMI)
      +CONFIG_DM_VIDEO=y
      +CONFIG_DISPLAY=y
      +CONFIG_VIDEO_ROCKCHIP=y
      +CONFIG_DISPLAY_ROCKCHIP_HDMI=y
3. turns on the 'dcache'-command (for a dcache flush) for our QA to
   fill the framebuffer using 'mw.l'
      +CONFIG_CMD_CACHE=y
4. turns on the 'bmp'-command
      +CONFIG_CMD_BMP=y
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Acked-by: NSimon Glass <sjg@chromium.org>

When enabling CONFIG_DISPLAY_ROCKCHIP_HDMI, compile-time warning for
the following implicitly defined functions are raised due to a missing
include directive:

  drivers/video/rockchip/rk_hdmi.c: In function 'rk_hdmi_probe':
  drivers/video/rockchip/rk_hdmi.c:150:2: warning: implicit declaration of function 'rk_setreg' [-Wimplicit-function-declaration]
    rk_setreg(&priv->grf->soc_con6, 1 << 15);
    ^~~~~~~~~
  drivers/video/rockchip/rk_hdmi.c:153:2: warning: implicit declaration of function 'rk_clrsetreg' [-Wimplicit-function-declaration]
    rk_clrsetreg(&priv->grf->soc_con6, 1 << 4,
    ^~~~~~~~~~~~

This change fixes this by including <asm/hardware.h> in rk_hdmi.c.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>