The following Kirkwood dtb build targets are currently missing:

kirkwood-openrd-base.dtb
kirkwood-openrd-client.dtb
kirkwood-openrd-ultimate.dtb

This patch adds them to the Makefile to fix the build error.
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Chris Packham <judge.packham@gmail.com>
Reviewed-by: NChris Packham <judge.packham@gmail.com>
Signed-off-by: NStefan Roese <sr@denx.de>

Enable DM_MMC for compliance with the driver model migration.
Signed-off-by: NPierre Bourdon <delroth@gmail.com>
Cc: Marek Behun <marek.behun@nic.cz>
Signed-off-by: NStefan Roese <sr@denx.de>

The new DM implementation currently does not support the Sheeva
88SV331xV5 specific quirk present in the legacy implementation. The
legacy code is thus kept for this SoC and others not yet migrated to
DM_MMC.
Signed-off-by: NPierre Bourdon <delroth@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Stefan Roese <sr@denx.de>
Reviewed-by: NStefan Roese <sr@denx.de>
Signed-off-by: NStefan Roese <sr@denx.de>

Commit c4bd12a7 ("i2c: mux: Generate longer i2c mux name") changed
the naming scheme of i2c devices within a mux. This broke references to
i2c@0 in the Turris Omnia board initialization code.
Signed-off-by: NPierre Bourdon <delroth@gmail.com>
Cc: Marek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Signed-off-by: NStefan Roese <sr@denx.de>

Various minor sandbox iumprovements
Fixes for tracing with sandbox
Refactoring for boot_get_fdt()

Pull request for UEFI sub-system for v2019.07-rc1 (3)

This patch series reworks the implementation of the `bootefi` command to
remove code duplication by using the LoadImage() boot service to load
binaries.

Missing short texts for UEFI protocols are added for display by the
`efidebug dh` command.

Missing parameter checks for AllocatePages() and CreateDeviceNode() are
implemented.

The constants for protocol GUIDs are changed to match the names in the UEFI
specification.

STM32 MCUs update:
- DT rework and alignment with DT kernel v4.20
- mmc: arm_pl180_mmci: Synchronize compatible with kernel v4.20
- mmc: stm32_sdmmc2: Synchronize properties with kernel v4.20
- configs: update for F746/769 boards

- Add support for Amlogic p200 & p201 Reference Designs
- Add Amlogic SoC information display
- Add support for the Libretech-AC AML-S805X-AC board
- Add Amlogic AXG reset compatible
- Add I2C support for Amlogic AXG
- Fix AXG PIN and BANK pinctrl definitions
- Fix regmap_read_poll_timeout warning about sandbox_timer_add_offset
- Add initial support for Amlogic G12A SoC and U200 board
- Enable PHY_REALTEK for selected boards
- Fix Khadas VIM2 README

- Add and enable brcmnand driver on a number of relevant platforms.
  Also add and enable LED drivers on more bcm platforms.
- Various ARMv8 fixes/improvements, including extending PSCI
  functionality.
- fs_loader improvments
- Various FIT/SPL improvements
- PCI bugfixes
- Poplar platform ethernet support
- MediaTek MMC improvements
- Android boot improvements

Fix below CP warning triggered by the 'iminfo' output in another patch:
WARNING: 'addrress' may be misspelled - perhaps 'address'?

Fixes: 4f1318b2 ("common: image: minimal android image iminfo support")
Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Acked-by: NMarek Vasut <marek.vasut@gmail.com>

According to Android image format [1], kernel image resides at 1 page
offset from the boot image address. Grab the magic number from there
and allow U-Boot to handle LZ4-compressed KNL binaries instead of
hardcoding compression type to IH_COMP_NONE. Other compression types,
if needed, can be added later.

Tested on H3ULCB-KF using the image detailed in [2].

[1] Excerpt from include/android_image.h
    +-----------------+
    | boot header     | 1 page
    +-----------------+
    | kernel          | n pages
    +-----------------+
    | ramdisk         | m pages
    +-----------------+
    | second stage    | o pages
    +-----------------+

[2] => iminfo 4c000000
    ## Checking Image at 4c000000 ...
    Android image found
    kernel size:      85b9d1
    kernel address:   48080000
    ramdisk size:     54ddbc
    ramdisk addrress: 4a180000
    second size:      0
    second address:   48000800
    tags address:     48000100
    page size:        800
    os_version:       1200012a (ver: 0.9.0, level: 2018.10)
    name:
    cmdline:          buildvariant=userdebug
Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>

If CONFIG_UNIT_TEST is enabled we should enable the individual tests by
default to ensure good test coverage.
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

PCI_MSI_FLAGS_MASKBIT was missing from include file,
add it.
Signed-off-by: NRamon Fried <ramon.fried@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The fdt_setprop_u32() function does everything that we need, so we
really only use the function as a convenience wrapper, in which case it
can simply be a static inline function.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Testing has shown that the current DM implementation of a platform /
board specific translation offset, as its needed for the SPL on MVEBU
platforms is buggy. The translation offset is confingured too late,
after the driver bind functions are run. This may result in incorrect
address translations. With the current implementation its not possible
to configure the offset earlier, as the DM code has not run at all.

This patch now removed the set_/get_translation_offset() calls and
moves the translation offset into the GD variable translation_offset.
This variable will get used when CONFIG_TRANSLATION_OFFSET is enabled.
This option is enabled only for MVEBU on ARM32 platforms, where its
currenty needed and configured in the SPL.
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Pierre Bourdon <delroth@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Tested-by: NPierre Bourdon <delroth@gmail.com>
Tested-by: NBaruch Siach <baruch@tkos.co.il>

Boards such as qemu-riscv, which receive their device tree at runtime,
for example from QEMU or firmware, are unable to add the appropriate
device tree properties to make devices available pre relocation.
Instead, they must rely on the DM_FLAG_PRE_RELOC flag to be set for the
required drivers.

Add the DM_FLAG_PRE_RELOC flag to the simple-bus driver to make devices
under it with drivers that have set the flag as well available pre
relocation for these boards.
Signed-off-by: NLukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>

Enable this by default so that tracing can be inspected if enabled. This
cannot rely on the 'imply' in lib/Kconfig since this method of enabling
tracing relates on an environment variable (FTRACE) and does not use
Kconfig.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This converts the following to Kconfig:
   CONFIG_TRACE_BUFFER_SIZE
   CONFIG_TRACE_EARLY_SIZE
   CONFIG_TRACE_EARLY
   CONFIG_TRACE_EARLY_ADDR
Signed-off-by: NSimon Glass <sjg@chromium.org>

This converts the following to Kconfig:
   CONFIG_TRACE
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present many functions in this file return -1. Update them to return a
valid error code. Also tidy up the 'return' statements at the same time,
since these should have a blank line before them.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This function may be called from tracing code, since that code needs to
read the timer and this often requires calling do_div(), which calls
__div64_32(). If this function is instrumented it causes an infinite loop,
since emitting a trace record requests the time, which in turn emits a
trace record, etc.

Update the prototype to prevent instrumentation code being added.
Signed-off-by: NSimon Glass <sjg@chromium.org>

These functions still use uint32_t and uint64_t but checkpatch now
requests that the kernel types be used instead. Update them as well as a
few resulting checkpatch errors.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This file should not include header files. They have already been included
by the time initcall.h is included. Also, document how to enable debugging
in this file.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This buffer is too small now that sandbox has grown in size. Increase it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

It is possible for this to happen if something goes wrong very early in
the init sequence. Add a check for this.
Signed-off-by: NSimon Glass <sjg@chromium.org>

These two buffers currently conflict if tracing is enabled. Move the
pre-console buffer and update the documentation.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This was really intended for debugging. Drop it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Allocation routines were adjusted to ensure that the returned addresses
are a multiple of the page size, but the header code was not updated to
take account of this. These routines assume that the header size is the
same as the page size which is unlikely.

At present os_realloc() does not work correctly due to this bug. The only
user is the hostfs 'ls' command, and only if the directory contains a
unusually long filename, which likely explains why this bug was not
caught earlier.

Fix this by doing the calculations using the obtained page size.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present if one of the initcalls fails on sandbox the address printing
is not help, e.g.:

  initcall sequence 0000557678967c80 failed at call 00005576709dfe1f (err=-96)

This is because U-Boot gets relocated high into memory and the relocation
offset (gd->reloc_off) does not work correctly for sandbox.

Add support for finding the base address of the text region (at least on
Linux) and use that to set the relocation offset. This makes the output
better:

  initcall sequence 0000560775957c80 failed at call 0000000000048134 (err=-96)

Then you use can use grep to see which init call failed, e.g.:

   $ grep 0000000000048134 u-boot.map
   stdio_add_devices

Of course another option is to run it with a debugger such as gdb:

   $ gdb u-boot
   ...
   (gdb) br initcall.h:41
   Breakpoint 1 at 0x4db9d: initcall.h:41. (2 locations)

Note that two locations are reported, since this function is used in both
board_init_f() and board_init_r().

   (gdb) r
   Starting program: /tmp/b/sandbox/u-boot
   [Thread debugging using libthread_db enabled]
   Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

   U-Boot 2018.09-00264-ge0c2ba9814-dirty (Sep 22 2018 - 12:21:46 -0600)

   DRAM:  128 MiB
   MMC:

Breakpoint 1, initcall_run_list (init_sequence=0x5555559619e0 <init_sequence_f>)
    at /scratch/sglass/cosarm/src/third_party/u-boot/files/include/initcall.h:41
41				printf("initcall sequence %p failed at call %p (err=%d)\n",
   (gdb) print *init_fnc_ptr
   $1 = (const init_fnc_t) 0x55555559c114 <stdio_add_devices>
   (gdb)
Signed-off-by: NSimon Glass <sjg@chromium.org>

When using boot scripts it can become quite hard to understand
which commands are actually executed during bootup (e.g. where
is a kernel image loaded from or which DTB is in use).

Shell scripts suffer from a similar problem and many shells address
this problem with a command execution tracer (e.g. BASH has xtrace,
which can be enabled by "set -x").

This patch introduces a command tracer for U-Boot, which prints
every command with its arguments before it is executed.
Signed-off-by: NChristoph Muellner <christoph.muellner@theobroma-systems.com>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

Our platform doesn't store the DTB into the Android image second area,
but rather copies the DTB to RAM from a dedicated dtb.img partition [0],
prior to booting the Android image by calling bootm.

Similar to [1], we find it useful to just call 'bootm' and have the
right DTB being passed to OS (assuming its address has been previously
stored in 'fdtaddr' by calling `fdt addr <dtb-addr>`).

Booting Android with DTB from 'fdtaddr' will only occur if:
 - No DTB is embedded in the second area of Android image
 - 'fdtaddr' points to a valid DTB in RAM

[0] https://source.android.com/devices/architecture/dto/partitions
[1] https://patchwork.ozlabs.org/patch/1046652/
    ("Support boot Android image without address on bootm command")
Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Prepare for booting Android images which lack any DTB in the second
area by using 'fdtaddr' environment variable as source/address of FDT.
No functional/behavioral change expected in this patch.
Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Increase the readability of boot_get_fdt().
No change in behavior is expected.
Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The 'no_fdt' goto label was introduced by v2015.01 commit [0] and it
had two review stages [1-2]. The *documented* purpose behind commit [0]
is (excerpt from commit description):

> allows both FDT and non-FDT kernels to boot by making the
> third parameter to the bootm/bootz optional

While [1] and [2] share the same goal, they have very different
implementations:
 - [1] was based on a very simple 'argc' check at function error out
   with returning success to the caller if the third parameter was NOT
   passed to bootm/bootz command. This approach had the downside of
   returning success to the caller even in case of legitimate internal
   errors, which should halt booting.
 - [2] added the "no_fdt" label and several "goto no_fdt" statements.
   This allowed to report the legitimate internal errors to the caller.

IOW the major difference between [1] and [2] is:
 - [1] boot w/o FDT if FDT address is not passed to boot{m,z,*}
 - [2] give *freedom* to the developer to boot w/o FDT from any
   (more or less) arbitrary point in the function flow (and here
   comes the peculiar aspect, which looks to be a leftover from [1])
   with the precondition that the 3rd argument (FDT address) is NOT
   provided to boot{m,z,*}. In practice, this means that only a subset
   of "goto no_fdt" end up booting w/o FDT while the other subset is
   returning an error to the caller.

This patch removes the peculiar behavior described above, such that
"goto no_fdt" performs really what it tells to the developer.

The motivation of this patch is to decrease the unneeded complexity
and increase the readability of boot_get_fdt().

[0] 48aead71 ("fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined")
[1] https://patchwork.ozlabs.org/patch/412923/
    ("[U-Boot,v1] fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined")
[2] https://patchwork.ozlabs.org/patch/415635/
    ("[U-Boot,v2] fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined")
Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Paranoid programming [1] lies at the foundation of proper software
development, but the repetitive zeroing-out of output arguments in the
context of the same function rather clutters the code and inhibits
further refactoring/optimization than is doing any good.

In boot_get_fdt(), we already perform zero/NULL-initialization of
*of_flat_tree and *of_size at the beginning of the function, so doing
the same at function error-out is redundant/superfluous.

Moreover, keeping the code unchanged might encourage the developers to
update *of_flat_tree and *of_size during some interim computations,
which is against the current design of boot_get_fdt(). Currently,
writing useful data into these arguments happens just before
successfully returning from boot_get_fdt() and it should better stay so.

[1] https://blog.regehr.org/archives/1106Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This fixes relaction isses with the PSCI_TABLE entries in
the psci_32_table and psci_64_table.

When using 32-bit adress pointers relocation was not being applied to
the tables, causing PSCI handlers to point to the un-relocated code
area. By using 64-bit data relocation is properly applied. The
handlers are thus in the "secure data" area, which is protected by
/memreserve/ in the FDT.
Signed-off-by: NLars Povlsen <lars.povlsen@microchip.com>

The cache flush of the kernel load area needs to be aligned outward to
the DMA cache alignment.  The operations are simpler if we think of this
as aligning the start down, ALIGN_DOWN(load, ARCH_DMA_MINALIGN), and
aligning the end up, ALIGN(load_end, ARCH_DMA_MINALIGN), and then find
the length of the flushed region by subtracting the former from the
latter.

Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: NTrent Piepho <tpiepho@impinj.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

When using memalign() in a scenario where U-Boot is configured for full
malloc support with simple malloc not explicitly enabled and before the
full malloc support is initialized, a memory block is being allocated
and returned without the alignment parameter getting honored.

Fix this issue by replacing the existing memalign pre-full malloc init
logic with a call to memalign_simple() this way ensuring proper alignment
of the returned memory block.

Fixes: ee038c58 ("malloc: Use malloc simple before malloc is fully initialized in memalign()")
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>

This patch adds a short message to the SPL NAND loader, which displays
the source and destinations addresses including the size of the
loaded image, like this:

U-Boot SPL 2019.04-rc3-00113-g486efd8aaf (Mar 15 2019 - 14:18:02 +0100)
Trying to boot from NAND
Loading U-Boot from 0x00040000 (size 0x000a0000) to 0x22900000

I find this message quite helpful - hopefully others do so as well.
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Add support for MediaTek MT8516 SoC. This include the file
that will initialize the SoC after boot and its device tree.
Signed-off-by: NFabien Parent <fparent@baylibre.com>
Reviewed-by: NTom Rini <trini@konsulko.com>