ARM: tegra: add IVC protocol implementation

IVC (Inter-VM Communication) protocol is a Tegra-specific IPC (Inter
Processor Communication) framework. Within the context of U-Boot, it is
typically used for communication between the main CPU and various
auxiliary processors. In particular, it will be used to communicate with
the BPMP (Boot and Power Management Processor) on Tegra186 in order to
manipulate clocks and reset signals.

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

ARM: tegra: unify Tegra186 Makefile a bit

Many files in arch/arm/mach-tegra are compiled conditionally based on
Kconfig variables, or applicable to all platforms. We can let the main
Tegra Makefile handle compiling (or not) those files to avoid each SoC-
specific Makefile needing to duplicate entries for those files. This
leaves the SoC-specific Makefiles to compile truly SoC-specific code.

In the future, we'll hopefully add Kconfig variables for all the other
files, and refactor those files, and so reduce the need for SoC-specific
Makefiles and/or ifdefs in the Makefiles.

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

ARM: tegra: split p2771-0000 build

There are multiple versions of p2771-0000 board. There are SW visible
incompatible differences between the versions, and they are relevant to
U-Boot. Create separate "A02" and "B00" defconfigs (named after the first
and/or only board rev the defconfig supports) so that users can select
which build they want.

With the minimal set of HW currently enabled in U-Boot, the differences
are irrelevant, hence the DT files aren't different. However, that will
change in a future patch.

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

ARM: tegra: fix Tegra186 DT GPIO binding header

Tegra186 uses different GPIO port IDs compared to previous chips. Make
sure the SoC DT file includes the correct GPIO binding header.

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

image: fix IH_ARCH_... values for uImage compatibility

Commit 555f45d8f916 ("image: Convert the IH_... values to enums")
accidentally changed some IH_ARCH_... values.

Prior to that commit, there existed a gap between IH_ARCH_M68K and
IH_ARCH_MICROBLAZE, like follows.

  #define IH_ARCH_SPARC64         11      /* Sparc 64 Bit */
  #define IH_ARCH_M68K            12      /* M68K         */
  #define IH_ARCH_MICROBLAZE      14      /* MicroBlaze   */
  #define IH_ARCH_NIOS2           15      /* Nios-II      */

The enum conversion broke the compatibility with existing uImage
files.  Reverting 555f45d8f916 will cause build error unfortunately,
so here is a more easy fix.

I dug the git history and figured out the gap was introduced by
commit 1117cbf2adac ("nios: remove nios-32 arch").  So, I revived
IH_ARCH_NIOS just for filling the gap.

I added comments to each enum block.  Once we assign a value to
IH_... it is not allowed to change it.

Acked-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

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

mtd: cfi_flash: fix polling for bit XSR.7 on Intel chips

flash_full_status_check() checks bit XSR.7 on Intel chips. This
should be done by only checking bit 7 and not by comparing the
whole status byte or word with 0x80.

This fixes the non-working block erase in the pflash emulation
of Qemu when used with the MIPS Malta board. MIPS Malta uses x32
mode to access the pflash device. In x32 mode Qemu mirrors the
lower 16 bits of the status word into the upper 16 bits. Thus
the CFI driver gets a status word of 0x8080 in x32 mode. If
flash_full_status_check() uses flash_isequal(), then it polls for
XSR.7 by comparing 0x8080 with 0x80 which never becomes true.

Reported-by: Alon Bar-Lev <alon.barlev@gmail.com>
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>

Merge git://git.denx.de/u-boot-fsl-qoriq

Signed-off-by: Tom Rini <trini@konsulko.com>
Conflicts:
arch/arm/cpu/armv8/Makefile
arch/arm/lib/bootm-fdt.c

ARMv8/ls1043ardb: Integrate FSL PPA

The PPA use PSCI to make secondary cores bootup. So when PPA was
enabled, add the CONFIG_ARMV8_PSCI to identify the SMP boot-method
between PSCI and spin-table.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

ARMv8/PSCI: Fixup the device tree for PSCI

Set the enable-method in the cpu node to PSCI, and create device
node for PSCI, when PSCI was enabled.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

ARMv8/Layerscape: switch SMP method accordingly

If the PSCI and PPA is ready, skip the fixup for spin-table and
waking secondary cores. Otherwise, change SMP method to spin-table,
and the device node of PSCI will be removed.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

ARMv8/layerscape: Add FSL PPA support

The FSL Primary Protected Application (PPA) is a software component
loaded during boot which runs in TrustZone and remains resident
after boot.

Use the secure firmware framework to integrate FSL PPA into U-Boot.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

ARMv8: add the secure monitor firmware framework

This framework is introduced for ARMv8 secure monitor mode firmware.
The main functions of the framework are, on EL3, verify the firmware,
load it to the secure memory and jump into it, and while it returned
to U-Boot, do some necessary setups at the 'target exception level'
that is determined by the respective secure firmware.

So far, the framework support only FIT format image, and need to define
the name of which config node should be used in 'configurations' and
the name of property for the raw secure firmware image in that config.
The FIT image should be stored in Byte accessing memory, such as NOR
Flash, or else it should be copied to main memory to use this framework.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

armv8: fsl-layerscape: add i/d-cache enable function to enable_caches

This function assume that the d-cache and MMU has been enabled earlier,
so it just created MMU table in main memory. But the assumption is not
always correct, for example, the early setup is done in EL3, while
enable_caches() is called when the PE has turned into another EL.

Define the function mmu_setup() for fsl-layerscape to cover the weak
one.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

armv8: layerscape: Convert to use common MMU framework

Drop platform code to create static MMU tables. Use common framework
to create MMU tables on the run. Tested on LS2080ARDB with secure and
non-secure ram scenarios.

Signed-off-by: York Sun <york.sun@nxp.com>

test: Adjust the of-platdata test run condition

This should be spl_of_platdata, since otherwise it will try to run on boards
that don't support of-platdata.

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

Various, unrelated tree-wide typo fixes.

    Fix a number of typos, including:

     * "compatble" -> "compatible"
     * "eanbeld" -> "enabled"
     * "envrionment" -> "environment"
     * "FTD" -> "FDT" (for "flattened device tree")
     * "ommitted" -> "omitted"
     * "overriden" -> "overridden"
     * "partiton" -> "partition"
     * "propogate" -> "propagate"
     * "resourse" -> "resource"
     * "rest in piece" -> "rest in peace"
     * "suport" -> "support"
     * "varible" -> "variable"

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>

configs: Add more CONFIG_ARMV7_PSCI_NR_CPUS entries

The code had assumed 4 CPUS before and now we have this configurable.
For now, set this to the previous default.

Cc: Chander Kashyap <k.chander@samsung.com>
Cc: Steve Rae <steve.rae@raedomain.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

armv8: mmu: Add support of non-identical mapping

Introduce virtual and physical addresses in the mapping table. This change
have no impact on existing boards because they all use idential mapping.

Signed-off-by: York Sun <york.sun@nxp.com>

armv8: mmu: split block if necessary

When page tables are created, allow later table to be created on
previous block entry. Splitting block feature is already working
with current code. This patch only rearranges the code order and
adds one condition to call split_block().

Signed-off-by: York Sun <york.sun@nxp.com>

armv8: mmu: house cleaning

Make setup_pgtages() and get_tcr() available for platform code to
customize MMU tables.
Remove unintentional call of create_table().

Signed-off-by: York Sun <york.sun@nxp.com>

armv8: Add tlb_allocated to arch global data

When secure ram is used, MMU tables have to be put into secure ram.
To use common MMU code, gd->arch.tlb_addr will be used to host TLB
entry pointer. To save allocated memory for later use, tlb_allocated
variable is added to global data structure.

Signed-off-by: York Sun <york.sun@nxp.com>

armv8: Move secure_ram variable out of generic global data

Secure_ram variable was put in generic global data. But only ARMv8
uses this variable. Move it to ARM specific data structure.

Signed-off-by: York Sun <york.sun@nxp.com>

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

ARM: PSCI: Make psci_get_cpu_stack_top local to armv7/psci.S

Now that we have a secure data section for storing variables, there
should be no need for platform code to get the stack address.

Make psci_get_cpu_stack_top a local function, as it should only be
used in armv7/psci.S and only by psci_stack_setup.

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

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>

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

Merge git://git.denx.de/u-boot-dm

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>

dm: Update the of-platdata README for the new features

Revise the content based on the v2 additions. This is kept as a separate
patch to avoid confusing those who have already reviewed the v1 series.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>

dm: Add a test for of-platdata

Add a simple test which checks that the of-platdata system is working
correctly. The sequence is as follows:

- SPL starts up and probes all the UCLASS_MISC drivers
- There are 3 of these in sandbox.dts
- Therefore there should be 3 U_BOOT_DEVICE() declarations in dt-platdata.c
- These should produce 3 sandbox_spl_test devices
- Each device prints out its platform data when probed
- This test checks for this output and compares it against expectations

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

test/py: Start sandbox SPL when enabled

When sandbox SPL is enabled we want to start that rather than U-Boot proper,
since some tests may rely on running it first.

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

test/py: Provide a way to get early console output

Some tests want to check the console output from SPL or U-Boot proper.
Provide a means to do this.

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

test/py: Note which console produced unexpected output

At present the SPL and U-Boot consoles both present the same error message
when the expected console output does not appear. Add "SPL" to the SPL error
message to resolve this ambiguity.

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

test/py: Handle testing with the sandbox_spl board

This board can sometimes be used for tests. Handle it the same way as
sandbox.

Note: I plan to drop the sandbox_spl board at some point and merge its
features into sandbox. So this commit may not be necessary.

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

rockchip: Use of-platdata for firefly-rk3288

As an experiment, move this board over to use of-platdata. This means that
its SPL configuration will come from C structures generated at build-time
from the device tree, instead of coming from the device tree at run-time.

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

rockchip: sdram: Update the driver to support of-platdata

Add support for of-platdata with rk3288 SDRAM initr. This requires decoding
the of-platdata struct and setting up the device from that. Also the driver
needs to be renamed to match the string that of-platdata will search for.

The platform data is copied from the of-platdata structure to the one used
by the driver. This allows the same code to be used with device tree and
of-platdata.

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

rockchip: sdram: Move all DT decoding to ofdata_to_platdata()

It is more correct to avoid touching the device tree in the probe() method.
Update the driver to work this way. Note that only SPL needs to fiddle with
the SDRAM registers, so decoding the platform data fully is not necessary in
U-Boot proper.

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

rockchip: syscon: Update to work with of-platdata

The syscon devices all end up having diffent driver names with of-platdata,
since the driver name comes from the first string in the compatible list.
Add separate device declarations for each one, and add a bind method to set
up driver_data correctly.

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

rockchip: Don't use spl_boot_device() with of-platdata

This function cannot look at the device tree when of-platdata is used.
Update the code to handle this.

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

rockchip: Move the MMC setup check earlier

When the boot ROM sets up MMC we don't need to do it again. Remove the
MMC setup code entirely.

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

rockchip: pinctrl: Update the rk3288 driver to support of-platdata

Add support for of-platdata with rk3288. This requires disabling access to
the device tree and renaming the driver to match the string that of-platdata
will search for.

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

rockchip: clk: Update the rk3288 driver to support of-platdata

Add support for of-platdata with rk3288. This requires decoding the
of-platdata struct and setting up the devices from that. Also the driver
needs to be renamed to match the string that of-platdata will search for.

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

rockchip: clk: Move all DT decoding to ofdata_to_platdata()

It is more correct to avoid touching the device tree in the probe() method.
Update the driver to work this way. Also add an error check on grf since if
that fails then we should not use it.

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

rockchip: mmc: Update the driver to support of-platdata

Add support for of-platdata with rk3288. This requires decoding the
of-platdata struct and setting up the device from that. Also the driver
needs to be renamed to match the string that of-platdata will search for.

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

rockchip: mmc: Move all DT decoding to ofdata_to_platdata()

It is more correct to avoid touching the device tree in the probe() method.
Update the driver to work this way.

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

rockchip: Update the sdram-channel property to support of-platdata

Add an extra byte so that this data is not byteswapped. Add a comment to
the code to explain the purpose.

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

rockchip: serial: Add an of-platdata driver for rockchip

Add a driver that works with of-platdata. It sets up the platform data and
calls the standard ns16550 driver.

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

dm: serial: ns16550: Update to support of-platdata

With of-platdata this driver cannot know the format of the of-platdata
struct, so we cannot use generic code for accessing the of-platdata. Each
SoC that uses this driver will need to set up ns16550's platdata for it.
So don't compile in the generic code.

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

dm: core: Add an implementation of regmap_init_mem_platdata()

Add an implementation of this function which mirrors the functions of the
automatic device-tree implementation. This can be used with of-platdata to
create regmaps.

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

dm: core: Move regmap allocation into a separate function

We plan to add a new way of creating a regmap for of-platdata. Move the
allocation code into a separate function so that it can be shared.

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

dm: sandbox: Enable of-platdata for sandbox_spl

Enable this feature so that we can use it for testing in sandbox_spl.

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

sandbox: Don't bring in the eeprom emulator in SPL

This driver should not be used in SPL since we do not have I2C support
enabled in SPL on sandbox.

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

dm: core: Expand platdata for of-platdata devices

Devices which use of-platdata have their own platdata. However, in many
cases the driver will have its own auto-alloced platdata, for use with the
device tree. The ofdata_to_platdata() method converts the device tree
settings to platdata.

With of-platdata we would not normally allocate the platdata since it is
provided by the U_BOOT_DEVICE() declaration. However this is inconvenient
since the of-platdata struct is closely tied to the device tree properties.
It is unlikely to exactly match the platdata needed by the driver.

In fact a useful approach is to declare platdata in the driver like this:

struct r3288_mmc_platdata {
struct dtd_rockchip_rk3288_dw_mshc of_platdata;
/* the 'normal' fields go here */
};

In this case we have dt_platadata available, but the normal fields are not
present, since ofdata_to_platdata() is never called. In fact driver model
doesn't allocate any space for the 'normal' fields, since it sees that there
is already platform data attached to the device.

To make this easier, adjust driver model to allocate the full size of the
struct (i.e. platdata_auto_alloc_size from the driver) and copy in the
of-platdata. This means that when the driver's bind() method is called,
the of-platdata will be present, followed by zero bytes for the empty
'normal field' portion.

A new DM_FLAG_OF_PLATDATA flag is available that indicates that the platdata
came from of-platdata. When the allocation/copy happens, the
DM_FLAG_ALLOC_PDATA flag will be set as well. The dtoc tool is updated to
output the platdata_size field, since U-Boot has no other way of knowing
the size of the of-platdata struct.

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

dm: Don't attach the device tree to SPL with of-platdata

When of-platdata is used in SPL we don't use the device tree. So there is no
point in attaching it. Adjust the Makefile to skip attaching the device tree
when of-platdata is enabled.

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

dtoc: Ignore the u-boot, dm-pre-reloc property

This property is not useful for of-platdata, so omit it.

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

dm: core: Rename DM_NAME_ALLOCED to DM_FLAG_NAME_ALLOCED

This is a flag. Adjust the name to be consistent with the other flags.

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

dm: spl: Bind in all devices in SPL with of-platdata

When CONFIG_OF_PLATDATA is enabled, we cannot use the u-boot,dm-pre-reloc
device tree property since the device tree is not available. However,
dt-platdata.c only includes devices which would have been present in the
device tree, and we can assume that all such devices are needed for SPL.
If they were not needed, they would have been omitted to save space.

So in this case, bind all devices regardless of the u-boot,dm-pre-reloc
setting. This avoids needing to add a DM_FLAG_PRE_RELOC to every driver,
thus affecting U-Boot proper also.

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

tiny-printf: Support assert()

At present assert() is not supported with tiny-printf, so when DEBUG is
enabled a build error is generated for each assert().

Add an __assert_fail() function to correct this. It prints a message and
then hangs.

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

Only build the libfdt python module if 'swig' is available

When swig is not available, we can still build correctly. So make this
optional. Add a comment about how to enable this build.

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

dm: Add a more efficient libfdt library

Add a Python version of the libfdt library which contains enough features to
support the dtoc tool. This is only a very bare-bones implementation. It
requires the 'swig' to build.

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

dm: Makefile: Build of-platdata files when the feature is enabled

Update the Makefile to call dtoc to create the C header and source files,
then build these into the image.

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

dm: Add a tool to generate C code from a device tree

This tool can produce C struct definitions and C platform data tables.
This is used to support the of-platdata feature.

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

dm: Add a library to provide simple device-tree access

This Python library provides a way to access the contents of the device
tree. It uses fdtget, so is inefficient for larger device tree files.

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

dm: Add a README for of-platdata

Add documentation on how this works, including the benefits and drawbacks.

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

dm: Add an option to enable the of-platdata feature

Add a Kconfig option to enable this feature.

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

dm: Don't include fdtdec functions when of-platdata is enabled

We cannot access the device tree in this case, so avoid compiling in the
various device-tree helper functions.

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

dm: serial: Add support for of-platdata

When this feature is enabled, we cannot access the device tree to find out
which serial device to use. Just use the first serial driver we find.

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

dm: clk: Add support for of-platdata

Add support for this feature in the core clock code.

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

dm: Add a header that provides access to the of-platdata structs

This header can be included from anywhere, but will only pull in the
of-platdata struct definitions when this feature is enabled (and only in
SPL).

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

dm: sandbox: Add a simple driver to test of-platdata

Add a driver which uses of-platdata to obtain its platform data. This can
be used to test the feature in sandbox. It displays the contents of its
platform data.

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

dm: syscon: Add support for of-platdata

Provide a new function which can cope with obtaining information from
of-platdata instead of the device tree.

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

dm: regmap: Add a dummy implementation for of-platdata

Add a placeholder for now so that this code will compile. It currently does
nothing.

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

dm: core: Don't use device tree with of-platdata

When CONFIG_SPL_OF_PLATDATA is enabled we should not access the device
tree. Remove all references to this in the core driver-model code.

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

dm: Makefile: Build of-platdata before SPL

Since SPL needs the of-platdata structures, build these before starting
to build any SPL components.

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

dm: spl: Don't set up device tree with of-platdata

When this feature is enabled, we should not access the device tree.

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

sandbox: Add a test device that uses of-platdata

Start up the test devices. These print out of-platdata contents, providing a
check that the of-platdata feature is working correctly.

The device-tree changes are made to sandbox.dts rather than test.dts. since
the former controls the of-platdata generation.

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

sandbox: Add a new sandbox_spl board

It is useful to be able to build SPL for sandbox. It provides additional
build coverage and allows SPL features to be tested in sandbox. However
it does not need worthwhile to always create an SPL build. It nearly
doubles the build time and the feature is (so far) seldom used.

So for now, create a separate build target for sandbox SPL. This allows
experimentation with this new feature without impacting existing workflows.

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