ARM: PSCI: Switch to per-CPU target PC storage in secure data section

Now that we have a secure data section and space to store per-CPU target
PC address, switch to it instead of storing the target PC on the stack.

Also save clobbered r4-r7 registers on the stack and restore them on
return in psci_cpu_on for Tegra, i.MX7, and LS102xA platforms.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

ARM: PSCI: Add helper functions to access per-CPU target PC storage

Now that we have a data section, add helper functions to save and fetch
per-CPU target PC.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

ARM: Add secure section for initialized data

The secure monitor may need to store global or static values within the
secure section of memory, such as target PC or CPU power status.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

ARM: Move __secure definition to common asm/secure.h

sunxi and i.mx7 both define the __secure modifier to put functions in
the secure section. Move this to a common place.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

sunxi: Define CONFIG_ARMV7_SECURE_MAX_SIZE for sun6i/sun7i

Both sun6i and sun7i have 64 KB of secure SRAM.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

ARM: Add CONFIG_ARMV7_SECURE_MAX_SIZE and check size of secure section

As the PSCI implementation grows, we might exceed the size of the secure
memory that holds the firmware.

Add a configurable CONFIG_ARMV7_SECURE_MAX_SIZE so platforms can define
how much secure memory is available. The linker then checks the size of
the whole secure section against this.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

ARM: PSCI: Remove unused psci_text_end symbol

psci_text_end was used to calculate the PSCI stack address following the
secure monitor text. Now that we have an explicit secure stack section,
this is no longer used.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

ARM: PSCI: Allocate PSCI stack in secure stack section

Now that we have a secure stack section that guarantees usable memory,
allocate the PSCI stacks in that section.

Also add a diagram detailing how the stacks are placed in memory.

Reserved space for the target PC remains unchanged. This should be
moved to global variables within a secure data section in the future.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

ARM: Add an empty secure stack section

Until now we've been using memory beyond psci_text_end as stack space
for the secure monitor or PSCI implementation, even if space was not
allocated for it.

This was partially fixed in ("ARM: allocate extra space for PSCI stack
in secure section during link phase"). However, calculating stack space
from psci_text_end in one place, while allocating the space in another
is error prone.

This patch adds a separate empty secure stack section, with space for
CONFIG_ARMV7_PSCI_NR_CPUS stacks, each 1 KB. There's also
__secure_stack_start and __secure_stack_end symbols. The linker script
handles calculating the correct VMAs for the stack section. For
platforms that relocate/copy the secure monitor before using it, the
space is not allocated in the executable, saving space.

For platforms that do not define CONFIG_ARMV7_PSCI_NR_CPUS, a whole page
of stack space for 4 CPUs is allocated, matching the previous behavior.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

ARM: PSCI: Add missing CONFIG_ARMV7_PSCI_NR_CPUS for PSCI enabled platforms

The original PSCI implementation assumed CONFIG_ARMV7_PSCI_NR_CPUS=4.
Add this to platforms that have not defined it, using CONFIG_MAX_CPUS if
it is defined, or the actual number of cores for the given platform.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

ARM: Page align secure section only when it is executed in situ

Targets that define CONFIG_ARMV7_SECURE_BASE will copy the secure section
to another address before execution.

Since the secure section in the u-boot image is only storage, there's
no reason to page align it and increase the binary image size.

Page align the secure section only when CONFIG_ARMV7_SECURE_BASE is not
defined. And instead of just aligning the __secure_start symbol, align
the whole .__secure_start section. This also makes the section empty,
so we need to add KEEP() to the input entry to prevent the section from
being garbage collected.

Also use ld constant "COMMONPAGESIZE" instead of hardcoded page size.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

sunxi: Add missing CONFIG_ARMV7_PSCI_NR_CPUS for sun7i

sun7i has 2 CPUs.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

sunxi: Move remaining PSCI assembly code to C

This patch finishes the rewrite of sunxi specific PSCI parts into C
code.

The assembly-only stack setup code has been factored out into a common
function for ARMv7. The GIC setup code can be renamed as psci_arch_init.
And we can use an empty stub function for psci_text_end.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

ARM: PSCI: Split out common stack setup code from psci_arch_init

Every platform has the same stack setup code in assembly as part of
psci_arch_init.

Move this out into a common separate function, psci_stack_setup, for
all platforms. This will allow us to move the remaining parts of
psci_arch_init into C code, or drop it entirely.

Also provide a stub no-op psci_arch_init for platforms that don't need
their own specific setup code.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

sunxi: Add defconfig and dts file for the Orange Pi Lite SBC

The Orange Pi Lite SBC is a small H3 based SBC, with 512MB RAM,
micro-sd slot, HDMI out, 2 USB-A connectors, 1 micro-USB connector,
sdio attached rtl8189ftv wifi and an ir receiver.

The dts file is identical to the one submitted to the upstream kernel.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>

sunxi: Sync sun8i-h3-orangepi-plus.dts with upstream

This enables extra USB controllers which enable use of the 3rd USB
port on the new Orange Pi Plus 2E variant.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>

sunxi: orangepi_pc: Add support for eMMC found on the Orange Pi PC Plus

The Plus variant of the Orange Pi PC has an eMMC, add support for this.

Note we are using the same u-boot defconfig / dts for both the regular
Orange Pi PC as well as the Orange Pi PC Plus.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>

sunxi: Use BROM stored boot_media value to determine our boot-source

Now that we know that the BROM stores a value indicating the boot-source
at the beginning of SRAM, use that instead of trying to recreate the
BROM's boot probing.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>

sunxi: Remove some unnecessary #ifdefs

We always define CONFIG_MISC_INIT_R on sunxi and misc_init_r is never
called in the spl, so the linker will optimize it and parse_spl_header(),
of which it is the only caller, away.

On the tests I've done (Orange Pi PC build) the SPL actually becomes
8 bytes smaller with this patch.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>

sunxi: Add support for multiple ethadrr-esses

Currently we fill ethaddr with a fixed unique address based on the SoCs
serial (from the sid) to make sure that boards which use the integrated
emac / gmac get a fixed mac rather then a random one.

On some boards the wifi does not come with a fixed mac either, so we need
to also set eth1addr.

This commit changes the ethaddr setting code to check for ethernet%d
aliases (as fdt_fixup_ethernet does) and set an ethaddr variable for
all present aliases.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>

net: Add EMAC driver for H3/A83T/A64 SoCs.

This patch add EMAC driver support for H3/A83T/A64 SoCs.
Tested on Pine64(A64-External PHY) and Orangepipc(H3-Internal PHY).

BIG Thanks to Andre for providing some of the DT code.

Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

sunxi: mmc: increase status register polling rate for data transfers

With a recent bunch of SD3.0 cards in our A20-based board we
experienced data transfer rates of about 250 KiB/s instead of 10 MiB/s
with previous cards from the same vendor (both 4 GB/class 10). By
increasing status register polling rate from 1 kHz to 1 MHz we were
able to reach the original transfer rates again. With the old cards
we now even reach about 16 MiB/s.

Signed-off-by: Tobias Doerffel <tobias.doerffel@ed-chemnitz.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

sunxi: FEL - Add the ability to recognize and auto-import uEnv-style data

The patch converts one of the "reserved" fields in the sunxi SPL
header to a fel_uEnv_length entry. When booting over USB ("FEL
mode"), this enables the sunxi-fel utility to pass the string
length of uEnv.txt compatible data; at the same time requesting
that this data be imported into the U-Boot environment.

If parse_spl_header() in the sunxi board.c encounters a non-zero
value in this header field, it will therefore call himport_r() to
merge the string (lines) passed via FEL into the default settings.
Environment vars can be changed this way even before U-Boot will
attempt to autoboot - specifically, this also allows overriding
"bootcmd".

With fel_script_addr set and a zero fel_uEnv_length, U-Boot is
safe to assume that data in .scr format (a mkimage-type script)
was passed at fel_script_addr, and will handle it using the
existing mechanism ("bootcmd_fel").

Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

sunxi: Support booting from SPI flash

Allwinner devices support SPI flash as one of the possible
bootable media type. The SPI flash chip needs to be connected
to SPI0 pins (port C) to make this work. More information is
available at:

    https://linux-sunxi.org/Bootable_SPI_flash

This patch adds the initial support for booting from SPI flash.
The existing SPI frameworks are not used in order to reduce the
SPL code size. Right now the SPL size grows by ~370 bytes when
CONFIG_SPL_SPI_SUNXI option is enabled.

While there are no popular Allwinner devices with SPI flash at
the moment, testing can be done using a SPI flash module (it
can be bought for ~2$ on ebay) and jumper wires with the boards,
which expose relevant pins on the expansion header. The SPI flash
chips themselves are very cheap (some prices are even listed as
low as 4 cents) and should not cost much if somebody decides to
design a development board with an SPI flash chip soldered on
the PCB.

Another nice feature of the SPI flash is that it can be safely
accessed in a device-independent way (since we know that the
boot ROM is already probing these pins during the boot time).
And if, for example, Olimex boards opted to use SPI flash instead
of EEPROM, then they would have been able to have U-Boot installed
in the SPI flash now and boot the rest of the system from the SATA
hard drive. Hopefully we may see new interesting Allwinner based
development boards in the future, now that the software support
for the SPI flash is in a better shape :-)

Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option
in a board defconfig, then building U-Boot and finally flashing
the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with
a help of the sunxi-fel tool:

   sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin

The device needs to be switched into FEL (USB recovery) mode first.
The most suitable boards for testing are Orange Pi PC and Pine64.
Because these boards are cheap, have no built-in NAND/eMMC and
expose SPI0 pins on the Raspberry Pi compatible expansion header.
The A13-OLinuXino-Micro board also can be used.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Revert "armv8: Enable CPUECTLR.SMPEN for coherency"

Upon further review this breaks most other platforms as we need to check
what core we're running on before touching it at all.

This reverts commit d73718f3236c520a92efa401084c658e6cc067f3.

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

Merge branch 'master' of git://git.denx.de/u-boot-x86

x86: link: Correct a failure in DRAM init

With the change to set up pinctrl after relocation, link fails to boot. Add
a special case in the link code to handle this.

Fixes: d8906c1f (x86: Probe pinctrl driver in cpu_init_r())

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: Add Advantech SOM-DB5800/SOM-6867 support

Add support for Advantech SOM-DB5800 with the SOM-6867 installed.
This is very similar to conga-qeval20-qa3-e3845 in that there is a
reference carrier board (SOM-DB5800) with a Baytrail based SoM (SOM-6867)
installed.

Currently supported:
 - 2x UART (From ITE EC on SOM-6867) routed to COM3/4 connectors on
   SOM-DB5800.
 - 4x USB 2.0 (EHCI)
 - Video
 - SATA
 - Ethernet
 - PCIe
 - Realtek ALC892 HD Audio
   Pad configuration for HDA_RSTB, HDA_SYNC, HDA_CLK, HDA_SDO
   HDA_SDI0 is set in DT to enable HD Audio codec.
   Pin defaults for codec pin complexs are not changed.

Not supported:
 - Winbond Super I/O (Must be disabled with jumpers on SOM-DB8500)
 - USB 3.0 (XHCI)
 - TPM

Signed-off-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

x86: baytrail: acpi: Hide internal UART per GNVS setting

If global NVS says internal UART is not enabled, hide it in the ASL
code so that OS won't see it.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: George McCollister <george.mccollister@gmail.com>
Tested-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

x86: acpi: Pack global NVS into ACPI table

Now that platform-specific ACPI global NVS is added, pack it into
ACPI table and get its address fixed up.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: George McCollister <george.mccollister@gmail.com>
Tested-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

x86: quark: Introduce ACPI global NVS

This introduces quark-specific ACPI global NVS structure, defined in
both C header file and ASL file.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

x86: baytrail: Introduce ACPI global NVS

This introduces baytrail-specific ACPI global NVS structure, defined in
both C header file and ASL file.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: George McCollister <george.mccollister@gmail.com>
Tested-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

x86: conga-qeval20-qa3: Add support for internal UART

This patch adds support to enable and use the internal BayTrail UART
instead of the one integrated in the Super IO Winbond chip. For this,
a 2nd defconfig file is added.

This is useful for tests done for the congatec SoM used on baseboards
without such a Super IO chip.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

x86: fsp: Wrap setup_internal_uart() call with CONFIG_INTERNAL_UART

For any FSP-enabled boards that want to enable debug UART support,
setup_internal_uart() will be called, but this API is only available
on BayTrail platform. Change to wrap it with CONFIG_INTERNAL_UART.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

x86: baytrail: Introduce a Kconfig option for the internal UART

There are quite a number of BayTrail boards that uses an external
SuperIO chipset to provide the legacy UART. For such cases, it's
better to have a Kconfig option to enable the internal UART.

So far BayleyBay and MinnowMax boards are using internal UART as
the U-Boot console, enable this on these two boards.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

pci: Add board_ prefix to should_load_oprom() and make it weak

For consistency with board_should_run_oprom(), do the same to
should_load_oprom(). Board support codes can provide this one
to override the default weak one.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

pci: Make load_oprom and run_oprom independent

At present should_load_oprom() calls board_should_run_oprom() to
determine whether oprom should be loaded. But sometimes we just
want to load oprom without running. Make them independent.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

pci: Remove CONFIG_ALWAYS_LOAD_OPROM

This option is defined at nowhere. Remove it.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Merge branch 'master' of git://git.denx.de/u-boot-spi

tools: patman: Handle missing 'END' in non-last commit of a series

The following python error:

Traceback (most recent call last):
  File "./tools/patman/patman", line 144, in <module>
    series = patchstream.FixPatches(series, args)
  File "./tools/patman/patchstream.py", line 477, in FixPatches
    commit = series.commits[count]
IndexError: list index out of range

is seen when:

- 'END' is missing in those tags
- those tags are put in the last part in a commit message
- the commit is not the last commit of the series

Add testing logic to see if a new commit starts.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

tools: patman: Handle missing blank line for 'Series-changes'

'Series-changes' uses blank line to indicate its end. If that is
missing, series internal state variable 'in_change' may be wrong.
Correct its state.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

tools: patman: Generate cover letter correctly when 'END' is missing

If 'END' is missing in a 'Cover-letter' section, and that section
happens to show up at the very end of the commit message, and the
commit is the last commit of the series, patman fails to generate
cover letter for us. Handle this in CloseCommit of patchstream.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

tools: patman: Handle tag sections without an 'END'

'Cover-letter', 'Series-notes' and 'Commit-notes' tags require an
'END' to be put at the end of its section. If we forget to put an
'END' in those sections, and these sections are followed by another
patman tag, patman generates incorrect patches. This adds codes to
handle such scenario.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

tools: patman: Use cover_match for 'Cover-letter'

Like other patman tags, use a new variable cover_match to indicate
a match for 'Cover-letter'.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

dm: Sort the uclass id in alphabetical order

Some uclass ids are out of order. Per the comments, sort them
in alphabetical order.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

sandbox: Find keyboard driver using driver model

The cros-ec keyboard is always a child of the cros-ec node. Rather than
searching the device tree, looking at the children. Remove the compat string
which is now unused.

Signed-off-by: Simon Glass <sjg@chromium.org>

fdt: x86: Tidy up a few COMPAT string definitions

The 'COMPAT_' part should appear only once so drop the duplicate part. It is
ignored anyway, but let's keep things consistent.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

fdt: Add a note to avoid adding new compatible strings

The list is shrinking and we should avoid adding new things. Instead, a
proper driver should be created with driver model.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

fdt: Drop unused exynos compatible strings

A few drivers have moved to driver model, so we can drop these strings.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>

x86: fdt: Drop the unused compatible strings in fdtdec

We have drivers for several more devices now, so drop the strings which are
no-longer used.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

common: block: fix compiler error with CONFIG_FASTBOOT_FLASH_MMC_DEV

This fixes the following compiler error:

common/fb_mmc.c: In function ‘fb_mmc_erase’:
common/fb_mmc.c:209:17: error: ‘struct blk_desc’ has no member named
‘block_erase’

Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>

dm: gpio: MPC85XX GPIO platform data support

Define a platform data structure for the MPC85XX GPIO driver to allow
use of the driver without device tree. Users should define the GPIO
blocks for their platform like this:
  struct mpc85xx_gpio_plat gpio_blocks[] = {
         {
                 .addr = 0x130000,
                 .ngpios = 32,
         },
         {
                 .addr = 0x131000,
                 .ngpios = 32,
         },
  };

  U_BOOT_DEVICES(my_platform_gpios) = {
         { "gpio_mpc85xx", &gpio_blocks[0] },
         { "gpio_mpc85xx", &gpio_blocks[1] },
  };

This is intended to build upon the recent submission of the base
MPC85XX driver from Mario Six. We need to use that new driver
without dts support and this patch gives us that flexibility.
This has been tested on a Freescale T2080 CPU, although only the first
GPIO block.

Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Reviewed-by: Mario Six <mario.six@gdsys.cc>
Tested-by: Mario Six <mario.six@gdsys.cc>
Acked-by: Simon Glass <sjg@chromium.org>

dm: dfu: mmc: Support CONFIG_BLK in DFU for MMC

Update the method of accessing the block device so that it works with
CONFIG_BLK enabled.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: spl: mmc: Support CONFIG_BLK in SPL MMC

Update the method of accessing the block device so that it works with
CONFIG_BLK enabled.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: mmc: msmsdhic: Drop old MMC code

Now that we have fully moved to driver model, drop the old code.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: mmc: Move dragonboard410c to use CONFIG_BLK and CONFIG_DM_MMC_OPS

Update this board to use driver model for block devices and MMC operations.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: mmc: msm_sdhci: Support CONFIG_BLK and CONFIG_DM_MMC_OPS

Add support for using driver model for block devices and MMC operations in
this driver.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: mmc: sdhci: Support CONFIG_BLK and CONFIG_DM_MMC_OPS

Add support for using driver model for block devices and MMC operations in
this driver.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: mmc: sdhci: Refactor configuration setup to support DM

Move the configuration setting into a separate function which can be used by
the driver-model code.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: sandbox: Convert to use CONFIG_CMD_MMC_OPS

Update the sandbox MMC emulation to use driver model for MMC operations.

Signed-off-by: Simon Glass <sjg@chromium.org>

rockchip: Add MAINTAINER files for kylin_rk3036, evb_rk3036

These boards should have maintainer entries. Add them.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: mmc: rockchip: Enable CONFIG_DM_MMC_OPS for all boards

Enable this option to move rockchip over to use driver model for MMC
operations.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: mmc: dwmmc: Support CONFIG_DM_MMC_OPS

Add support to dwmmc for using driver model for MMC operations.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: mmc: Add a way to use driver model for MMC operations

The driver model conversion for MMC has moved in small steps. The first step
was to have an MMC device (CONFIG_DM_MMC). The second was to use a child
block device (CONFIG_BLK). The final one is to use driver model for MMC
operations (CONFIG_DM_MMC_OP). Add support for this.

The immediate priority is to make all boards that use DM_MMC also use those
other two options. This will allow them to be removed.

Signed-off-by: Simon Glass <sjg@chromium.org>

rockchip: Disable CONFIG_SDHCI

This option is not actually needed for rockchip boards. Drop it, since it
will not support driver-model MMC operation support.

Signed-off-by: Simon Glass <sjg@chromium.org>

mmc: Move tracing code into separate functions

Move this code into separate functions so that it can be used from the uclass
also. Add static inline versions for when the option is disabled.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: mmc: rockchip: Support only CONFIG_BLK

Since all Rockchip boards use CONFIG_BLK, we can remove this old code.

Signed-off-by: Simon Glass <sjg@chromium.org>

mmc: Move MMC boot code into its own file

Rather than having an #ifdef in the main mmc.c file, control this feature
from the Makefile by moving the code into its own file.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: mmc: Move non-CONFIG_BLK code into mmc_legacy.c

Rather than having #ifdef in mmc.c, move this code into the legacy file.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: mmc: Move CONFIG_BLK code into the mmc uclass

Rather than having #ifdef in mmc.c, move this code into the uclass file.

Signed-off-by: Simon Glass <sjg@chromium.org>

mmc: Add function declarations for mmc_bread() and mmc_switch_part()

These private functions are used both in the driver-model implementation and
in the legacy code. Add them to the header.

Signed-off-by: Simon Glass <sjg@chromium.org>

rockchip: Use 'select' instead of defaults in Kconfig

Rockchip uses driver model for all subsystems. Specify this in the arm
Kconfig rather than as defaults in the Rockchip Kconfig. This means that
boards cannot turn these options off, which seems correct.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: mmc: dwmmc: Add comments to the dwmmc setup functions

These comments were missed when the original code was written. Add them to
help people port their drivers over.

Signed-off-by: Simon Glass <sjg@chromium.org>

Prepare v2016.07

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

doc: ARMv8: add README.pine64

Since we lack information about the DRAM initialization for the
Allwinner A64 SoC, booting any A64 based board like the Pine64 is a bit
involved at the moment.
Add a README file to explain the process.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Move to board/sunxi/ from doc/]
Signed-off-by: Tom Rini <trini@konsulko.com>

mkimage -l is broken for images after gpimage

Because a gpimage cannot be detected, a false
GP header is printed instead of checking
for further image types.

Move gpimage as last to be linked, letting check
all other image types and printing a GP header just
in case no image is detected.

Signed-off-by: Stefano Babic <sbabic@denx.de>

git-mailrc: add rockchip alias

It's easier to Cc rockchip maintainers on rockchip-releated patches.

Signed-off-by: jk <jk.kernel@gmail.com>

dm: spi: Read default speed and mode values from DT

In case of DT boot, don't read default speed and mode for SPI from
CONFIG_*, instead read from DT node. This will make sure that boards
with multiple SPI/QSPI controllers can be probed at different
bus frequencies and SPI modes.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

ARM: dts: dra7x: Support QSPI MODE-0 operation at 64MHz

According to Data Manual(SPRS915P) of AM57x, TI QSPI controller on
DRA74(rev 1.1+)/DRA72 EVM can support up to 64MHz in MODE-0, whereas
MODE-3 is limited to 48MHz. Hence, switch to MODE-0 for better
throughput.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

defconfig: k2g_evm_defconfig: Enable Cadence QSPI controller

Enable Cadence QSPI controller support to use QSPI on K2G SoC. Also
enable Spansion flash support to access s25fl512s flash present on K2G
QSPI bus.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

ARM: dts: K2G: Add support for QSPI controller

K2G SoC has a Cadence QSPI controller to communicate with NOR flash
devices. Add DT nodes to support the same.
Also, K2G EVM has a s25fl512s flash connect to QSPI bus at CS 0. Add nor
flash slave node for the same.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

spi: cadence_quadspi: Enable QUAD mode based on DT data

Instead of relying on CONFIG_SPI_FLASH_QUAD to be defined to enable QUAD
mode, make use of mode_rx field of dm_spi_slave_platdata to determine
whether to enable or disable QUAD mode. This is necessary to support
muliple SPI controllers where one of them may not support QUAD mode.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Tested-by: Marek Vasut <marex@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagan Teki <jteki@openedev.com>

spi: cadence_qspi_apb: Support 32 bit AHB address

AHB address can be as long as 32 bit, hence remove the
CQSPI_REG_INDIRECTRDSTARTADDR mask. Since AHB address is passed from DT
and read as u32 value, it anyway does not make sense to mask upper bits.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Tested-by: Marek Vasut <marex@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagan Teki <jteki@openedev.com>

defconfig: k2g_evm_defconfig: enable SPI driver model

Enable SPI and SPI Flash driver model as K2G SPI controller driver
supports driver model.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

ARM: dts: k2g: add support for Davinci SPI controller

K2G SoC has 4 SPI instances that are compatible with davinci_spi
controller(present on previous generation of Keystone2 devices). Add DT
nodes for the same. K2G EVM has a N25Q128A13 SPI NOR flash connected on
SPI-1. Add DT bindings for the same.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

defconfig: k2l_evm_defconfig: enable SPI driver model

Enable SPI and SPI Flash driver model as K2L SPI controller driver
supports driver model.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

ARM: dts: k2l: Enable Davinci SPI controller

Now that davinci_spi driver has been converted to DM framework, enable
the same in DT. Also add "spi-flash" as compatible property to
n25q128a11 node as it is required for flash device to be probed in
U-Boot.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

defconfig: k2e_evm_defconfig: enable SPI driver model

Enable SPI and SPI Flash driver model as K2E SPI controller driver
supports driver model.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

ARM: dts: k2e: Enable Davinci SPI controller

Now that davinci_spi driver has been converted to DM framework, enable
the same in DT. Also add "spi-flash" as compatible property to
n25q128a11 node as it is required for flash device to be probed in
U-Boot.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

defconfig: k2hk_evm_defconfig: enable SPI driver model

Enable SPI and SPI Flash driver model as K2HK SPI controller driver
supports driver model.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

ARM: dts: k2hk: Enable Davinci SPI controller

Now that davinci_spi driver has been converted to DM framework, enable
the same in DT. Also add "spi-flash" as compatible property to
n25q128a11 node as it is required for flash device to be probed in
U-Boot.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

ARM: dts: keystone2: add SPI aliases for davinci SPI nodes

Add aliases for SPI nodes in order for it to be probed by the DM
framework.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

keystone2: spi: do not define DM_SPI and DM_SPI_FLASH for SPL build

Since Keystone2 devices do not have support DM in SPL, do not define
DM_SPI and DM_SPI_FLASH for SPL build.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>

spi: davinci_spi: Convert to driver to adapt to DM

Convert davinci_spi driver so that it complies with SPI DM framework.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jteki@openedev.com>

dm: core: implement dev_map_physmem()

This API helps to map physical register addresss pace of device to
virtual address space easily. Its just a wrapper around map_physmem()
with MAP_NOCACHE flag.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Suggested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jteki@openedev.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jagan Teki <jteki@openedev.com>

armv8: Enable CPUECTLR.SMPEN for coherency

For A53, data coherency is enabled only when the CPUECTLR.SMPEN bit is
set. The SMPEN bit should be set before enabling the data cache.
If not enabled, the cache is not coherent with other cores and
data corruption could occur.

For A57/A72, SMPEN bit enables the processor to receive instruction
cache and TLB maintenance operations broadcast from other processors
in the cluster. This bit should be set before enabling the caches and
MMU, or performing any cache and TLB maintenance operations.

Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com>
Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>

test/py: support 'memstart =' in u_boot_utils.find_ram_base()

Some archs like MIPS or PPC have a different 'bdinfo' output
than ARM regarding the memory configuration. Also support
'memstart = 0x*' in u_boot_utils.find_ram_base() to make
all tests requiring the RAM base working on those archs.

Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Acked-by: Stephen Warren <swarren@nvidia.com>

test/py: strip VT100 codes from match buffer

Prior to this patch, any VT100 codes emitted by U-Boot are considered part
of a command's output, which often causes tests to fail. For example,
test_env_echo_exists executes printenv, and then considers any text on a
line before an = sign as a valid U-Boot environment variable name. This
includes any VT100 codes emitted. When the test later attempts to use that
variable, the name would be invalid since it includes the VT100 codes.
Solve this by stripping VT100 codes from the match buffer, so they are
never seen by higher level test code.

The codes are still logged unmodified, so that users can expect U-Boot's
exact output without interference. This does clutter the log file a bit.
However, it allows users to see exactly what U-Boot emitted rather than a
modified version, which hopefully is better for debugging. It's also much
simpler to implement, since logging happens as soon as text is received,
and so stripping the VT100 codes from the log would require handling
reception and stripping of partial VT100 codes.

Signed-off-by: Stephen Warren <swarren@nvidia.com>

arm: Fix setjmp (again)

Commit e677724 (arm: Fix setjmp) added code to fix compilation of the setjmp
code path with thumv1. Unfortunately it missed a constraint that the adr
instruction can only refer to 4 byte aligned offsets.

So this patch adds the required alignment hooks to make compilation
work again even when setjmp doesn't happen to be 4 byte aligned.

Signed-off-by: Alexander Graf <agraf@suse.de>
Tested-by: Tom Rini <trini@konsulko.com>

SPL: tiny-printf: avoid any BSS usage

As printf calls may be executed quite early, we should avoid using any
BSS stored variables, since some boards put BSS in DRAM, which may not
have been initialised yet.
Explicitly mark those "static global" variables as belonging to the
.data section, to keep tiny-printf clear of any BSS usage.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>