net: davinci_emac: drop support for unused PHYs

The boards with SoCs from the DaVinci DM* family used to come with
different PHYs that needed special support implemented in mach-davinci.

Since the support for these chips has long been removed, we can now
drop this unnused code from the emac driver.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

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

- Misc MMC, FPGA bridge, general SoCFPGA fixes

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

- DaVinci updates

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

- Fix in kwbimage (return code checking) (Young Xiao)
- Misc updates to Turris Omnia (Marek)

ARM: davinci: Remove unused functions from header

There are a few functions defined in the header file, but they are
not referenced by any Davinci code.  In order to make a general
function in the future with static function declarations, this
patch will remove the references all together.

Signed-off-by: Adam Ford <aford173@gmail.com>

usb: ohci: Re-enable commented out delay

There is a delay function that was commented out.  This patch
re-enables it, because it will be needed for da850 ohci support.

Signed-off-by: Adam Ford <aford173@gmail.com>

Merge branch '2019-05-03-master-imports'

- Various btrfs fixes
- Various TI platform fixes
- Other fixes (cross build, taurus update, Kconfig help text)

fs: btrfs: fix btrfs methods return values on failure

The btrfs implementation methods .ls(), .size() and .read() returns 1 on
failure, but the command handlers expect values <0 on failure.

For example if given a nonexistent path, the load command currently
returns success, and hush scripting does not work.

Fix this by setting return values of these methods to -1 instead of 1 on
failure.

Signed-off-by: Marek Behún <marek.behun@nic.cz>

tools/Makefile: fix HOSTCFLAGS with CROSS_BUILD_TOOLS

When CROSS_BUILD_TOOLS is set, set HOSTCFLAGS to CFLAGS otherwise CC
will be used with HOSTCFLAGS which seems wrong

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

ARM: dts: logicpd-som-lv: Fix MMC1 card detect

The card detect pin was incorrectly using IRQ_TYPE_LEVEL_LOW
instead of GPIO_ACTIVE_LOW when reading the state of the CD pin.

Without this patch, MMC1 won't be detected.

This is the same patch submitted to linux-omap, but I was hoping
to get it applied to U-Boot without having to wait for the
linux adoption and then backporting.

Fixes: 5448ff33f281 ("ARM: DTS: Resync Logic PD SOM-LV 37xx
devkit with Linux 4.18-RC4")

Signed-off-by: Adam Ford <aford173@gmail.com>

README: davinci: update the documentation for DaVinci

The DM* family of SOCs is no longer supported. We now support the
omap-l138 lcdk board and Lego EV3 platform. Reflect those changes
in the README.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>

ti: Add am335x-pocketbeagle to am335x_evm_defconfig.

Add am335x-pocketbeagle to CONFIG_OF_LIST in am335x_evm_defconfig.

Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

ti: Add device-tree for am335x-pocketbeagle.

Add device-tree files from linux 5.1-rc7 needed to complete support
for PocketBeagle.

Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm: dts: k3-am654: Sync IOPAD macros with Linux

Transition to the IOPAD macros as used in Linux in which the pin mux
mode is specified using a dedicated parameter while also dropping the
related MUX_MODEx macros that are no longer needed. This transition
will allow us to keep both Linux and U-Boot DTS in sync more easily.
While at it also align the file name of the include file itself and
update any references accordingly.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

at91: cleanup taurus port

- at91sam9g20-taurus.dts: use labels
- cleanup taurus port to compile clean with
  current mainline again. SPL has no serial
  output anymore, so it fits into SRAM.

Signed-off-by: Heiko Schocher <hs@denx.de>

firmware: ti_sci: Always request response from firmware

TI-SCI firmware will only respond to messages when the
TI_SCI_FLAG_REQ_ACK_ON_PROCESSED flag is set. Most messages
already do this, set this for the ones that do not.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Tested-by: Alejandro Hernandez <ajhernandez@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>

lib: Kconfig: fix help text for GZIP

commit 95f4bbd581cf ("lib: fdt: Allow LZO and GZIP DT compression in U-Boot")

introduced Kconfig option for gzip in U-Boot, but help text
says gzip for SPL, which is wrong. Fix this.

Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Marek Vasut <marex@denx.de>

lib/vsprintf: remove #include <uuid.h> from vsprintf.c

common.h already includes uuid.h

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

fs: btrfs: Do not print mount fail message when not btrfs filesystem

Other filesystem drivers don't do this.

Signed-off-by: Marek Behún <marek.behun@nic.cz>

fs: correct comments for fs_read() and write()

The existing comments where confusing read and write. The comment for
fs_write() had:
"@addr: The address to read into"

So let's rework the comments and format them in Sphinx style.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

armv7R: dts: k3: am654: Switch DMSC TX message thread ID

Switch from using the high priority DMSC transmit message queue used
by the secure R5 MCU island boot context to the low priority message
queue. While the change in priority is irrelevant for the current boot
architecture it however gives us access to a deeper message queue that
will allow us to buffer more messages. This is an important aspect when
sending several messages without requesting and waiting for a response
in a row which is a communication scheme used during core shutdown for
example. See AM654 TISCI User Guide for additional details.

Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

board: am335x: Drop duplicate pinmux configuration

In commit ad6054f1fe128f797b6eb2964afca6674b584785 where support for the
Sancloud BeagleBone Enhanced (BBE) was added, new conditional
configuration of either MII pin muxing or RGMII pin muxing is done
depending on the board type. However, the old call to set up MII pin
muxing was not removed.

This may result in misconfiguration of the pin muxing for the BBE or
duplicate configuration for other boards and so we remove this obsolete
call.

Signed-off-by: Paul Barker <paul.barker@sancloud.co.uk>

watchdog: Kconfig: update WDT help message

Restart operation never exists and reset operation never
makes the watchdog expire immediately but expire_now operation
does.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Stefan Roese <sr@denx.de>

dma: ti: k3-udma: Do not touch RT registers before channel configuration

Upcoming sysfw (2019.03) will not open the channelized firewalls during
init, it only going to do so in response to the channel configuration
message.

Remove the channel state checks done before the channel configuration and
move it after the configuration for warning purposes.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>

firmware: ti_sci: Fix TISCI mailbox receive timeout handling

An earlier commit converted the TISCI receive timeouts to be specified
in ms rather than us however it failed to take this change into account
when passing the actual timeout to be used when invoking the mailbox
receive API. This leads to the actual timeout to be 1,000 times shorter
than expected and as a result certain TISCI operations would fail.

Fix the issue by converting the timeout declared in ms to us on the fly
as expected by the respective API.

Fixes: fd6b40b1ba20 ("firmware: ti_sci: Add support for NAVSS resource management")
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

MAINTAINERS, git-mailrc: Update the mmc maintainer

Update the mmc maintainer from Jaehoon to me.

Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Marek Vasut <marex@denx.de>

drivers: dma: ti: k3-udma: Extract packet data only when Meta data is not NULL

Currently packet data is wrongly extracted when metadata is NULL.
Fix it and negate the if check.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

Merge tag 'efi-2019-07-rc2' of git://git.denx.de/u-boot-efi

Pull request for UEFI sub-system for v2019.07-rc2

This pull request provides error fixes for the handling of GPT partitions
and for the UEFI subsystem.

arm: mvebu: turris_omnia: enable defconfig options needed by vendor

This options will be enabled by default by CZ.NIC shipped U-Boot. Enable
them in defconfig.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: add GPIO support to defconfig

Add support for the gpio command and driver for the I2C connected
pca9538 controller, to be able to determine if SFP module is present in
the Turris Omnia router.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

i2c: mvtwsi: fix reading status register after interrupt

The twsi_wait function reads the control register for interrupt flag,
and if interrupt flag is present, it immediately reads status register.

On our device this sometimes causes bad value being read from status
register, as if the value was not yet updated.

My theory is that the controller does approximately this:
  1. sets interrupt flag in control register,
  2. sets the value of status register,
  3. causes an interrupt

In U-Boot we do not use interrupts, so I think that it is possible that
sometimes the status register in the twsi_wait function is read between
points 1 and 2.

The bug does not appear if I add a small delay before reading status
register.

Wait 100ns (which in U-Boot currently means 1 us, because ndelay(i)
function calls udelay(DIV_ROUND_UP(i, 1000))) before reading the status
register.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Mario Six <mario.six@gdsys.cc>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: add RESET button handling

There is a Factory RESET button on the back side of the Turris Omnia
router. When user presses this button before powering the device up and
keeps it pressed, the microcontroller prevents the main CPU from booting
and counts how long the RESET button is being pressed (and indicates
this by lighting up front LEDs).

The idea behind this is that the user can boot the device into several
Factory RESET modes.

This patch adds support for U-Boot to read into which Factory RESET mode
the user booted the device. The value is an integer stored into the
omnia_reset environment variable. It is 0 if the button was not pressed
at all during power up, otherwise it is the number identifying the
Factory RESET mode.

This patch also changes bootcmd to a special hardcoded value if Factory
RESET button was pressed during device powerup. This special bootcmd
value sets the colors of all the LEDs on the front panel to green and
then tries to load the rescue image from the SPI flash memory and boot
it.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: fix regdomain env var setting

The regdomain environment variable is set according to value read from
EEPROM. This has to be done in board_late_init, after the environment
variables are read from SPI. Select CONFIG_BOARD_LATE_INIT in Kconfig
for the Turris Omnia target.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_*: remove watchdog include

Since board watchdog is now unified and not handled in board files,
remove the unnecessary includes.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: print board info as Turris Mox

Unify the way how Omnia and Mox print board information (RAM size and
serial number).

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: refactor more code

Refactor RAM size reading from EEPROM in preparation for next patch.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: move ATSHA204A from defconfig to Kconfig

This driver is required for Turris Omnia to read ethernet addresses.
Move the dependency from turris_omnia_defconfig to Kconfig.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: fix checkpatch warnings

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: refactor I2C accessing code

Refactor code which accesses the microcontroller and EEPROM via I2C.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: add SCSI as boot target

If SCSI is enabled, U-Boot should try to boot also from SCSI device on
Turris Omnia.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: move I2C dependencies to Kconfig

The I2C dependencies are defined in include/configs/turris_omnia.h,
because Turris Omnia won't boot correctly without I2C support.

Move these dependencies to Kconfig, so that they are selected if Turris
Omnia is selected as target.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: remove legacy macros from board header

These are not needed if MMC and SCSI DM drivers are used.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: use AHCI and SATA driver model

Enable AHCI, SCSI and SATA for compliance with the driver model
migration.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: add XHCI to defconfig

Add XHCI_HOST and XHCI_MVEBU to defconfig, so that user's can by default
boot from USB on Turris Omnia.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: remove redundant code

The i2c slave disabling is done by mvtwsi driver and is not needed here.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Acked-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>

kwbimage: fixing the issue with proper return code checking

EVP_VerifyFinal would return one of three values:
1 if the data is verified to be correct;
0 if it is incorrect;
-1 if there is any failure in the verification process.

The varification in unpatched version is wrong, since it ignored
the return value of -1.

The bug allows a malformed signature to be treated as a good
signature rather than as an error. This issue affects the
signature checks on DSA ans ECDSA keys used with SSL/TLS.

This issue is similar to CVE-2008-5077, CVE-2009-0021,
CVE-2009-0025, CVE-2009-0046 ~ CVE-2009-0049.

Signed-off-by: Young Xiao <92siuyang@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>

lib: uuid: Fix unseeded PRNG on RANDOM_UUID=y

The random uuid values (enabled via CONFIG_RANDOM_UUID=y) on our
platform are always the same. Below is consistent on each cold boot:

 => ### interrupt autoboot
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=d117f98e-6f2c-d04b-a5b2-331a19f91cb2
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=ad5ec4b6-2d9f-8544-9417-fe3bd1c9b1b3
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=cceb0b18-39cb-d547-9db7-03b405fa77d4
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=d4981a2b-0478-544e-9607-7fd3c651068d
 => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
 ...
 uuid_gpt_misc=6d6c9a36-e919-264d-a9ee-bd00379686c7

While the uuids do change on every 'gpt write' command, the values
appear to be taken from the same pool, in the same order.

Assuming U-Boot with RANDOM_UUID=y is deployed on a large number of
devices, all those devices would essentially expose the same UUID,
breaking the assumption of system/RFS/application designers who rely
on UUID as being globally unique (e.g. a database using UUID as key
would alias/mix up entries/records due to duplicated UUID).

The root cause seems to be simply _not_ seeding PRNG before generating
a random value. It turns out this belongs to an established class of
PRNG-specific problems, commonly known as "unseeded randomness", for
which I am able to find below bugs/CVE/CWE:
 - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0285
   ("CVE-2015-0285 openssl: handshake with unseeded PRNG")
 - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-9019
   ("CVE-2015-9019 libxslt: math.random() in xslt uses unseeded
   randomness")
 - https://cwe.mitre.org/data/definitions/336.html
   ("CWE-336: Same Seed in Pseudo-Random Number Generator (PRNG)")

The first revision [1] of this patch updated the seed based on the
output of get_timer(), similar to [4].

There are two problems with this approach:
 - get_timer() has a poor _ms_ resolution
 - when gen_rand_uuid() is called in a loop, get_timer() returns the
   same result, leading to the same seed being passed to srand(),
   leading to the same uuid being generated for several partitions
   with different names

The above drawbacks have been addressed in the second version [2].
In its third revision (current), the patch reworded the description
and summary line to emphasize it is a *fix* rather than an improvement.

Testing [3] consisted of running 'gpt write mmc 1 $partitions' in a
loop on R-Car3 for several minutes, collecting 8844 randomly generated
UUIDS. Two consecutive cold boots are concatenated in the log.
As a result, all uuid values are unique (scripted check).

Thanks to Roman, who reported the issue and provided support in fixing.

[1] https://patchwork.ozlabs.org/patch/1091802/
[2] https://patchwork.ozlabs.org/patch/1092945/
[3] https://gist.github.com/erosca/2820be9d554f76b982edd48474d0e7ca
[4] commit da384a9d7628 ("net: rename and refactor eth_rand_ethaddr() function")

Reported-by: Roman Stratiienko <roman.stratiienko@globallogic.com>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

cmd: gpt: fix and tidy up help message

Apply the following changes:
 - Guard the 'gpt read' command by 'ifdef CONFIG_CMD_GPT_RENAME',
   since 'gpt read' is not available on CMD_GPT_RENAME=n
 - Prefix the {read,swap,rename} commands with one space for consistency
 - Prefix the 'guid' commands with 'gpt' for consistency

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

disk: efi: Fix memory leak on 'gpt verify'

Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:

 => ### interrupt autoboot
 => gpt verify mmc 1
 No partition list provided - only basic check
 Verify GPT: success!
 => ### keep calling 'gpt verify mmc 1'
 => ### on 58th call, we are out of memory:
 => gpt verify mmc 1
 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
 GPT: Failed to allocate memory for PTE
 gpt_verify_headers: *** ERROR: Invalid Backup GPT ***
 Verify GPT: error!

This is caused by calling is_gpt_valid() twice (hence allocating pte
also twice via alloc_read_gpt_entries()) while freeing pte only _once_
in the caller of gpt_verify_headers(). Fix that by freeing the pte
allocated and populated for primary GPT _before_ allocating and
populating the pte for backup GPT. The latter will be freed by the
caller of gpt_verify_headers().

With the fix applied, the reproduction scenario [1-2] has been run
hundreds of times in a loop w/o running into OOM.

[1] gpt verify mmc 1
[2] gpt verify mmc 1 $partitions

Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

disk: efi: Fix memory leak on 'gpt guid'

Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:

 => ### interrupt autoboot
 => gpt guid mmc 1
 21200400-0804-0146-9dcc-a8c51255994f
 success!
 => ### keep calling 'gpt guid mmc 1'
 => ### on 59th call, we are out of memory:
 => gpt guid mmc 1
 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
 GPT: Failed to allocate memory for PTE
 get_disk_guid: *** ERROR: Invalid GPT ***
 alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
 GPT: Failed to allocate memory for PTE
 get_disk_guid: *** ERROR: Invalid Backup GPT ***
 error!

After some inspection, it looks like get_disk_guid(), added via v2017.09
commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"),
unlike other callers of is_gpt_valid(), doesn't free the memory pointed
out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid()
via alloc_read_gpt_entries().

With the fix applied, the reproduction scenario has been run hundreds
of times ('while true; do gpt guid mmc 1; done') w/o running into OOM.

Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: description of efi_add_handle()

Correct the comments describing function efi_add_handle().

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_selftest: test exit_data

Amend the unit test 'start image exit' to transfer a string as exit data.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: implement support of exit data

In case of a failure exit data may be passed to Exit() which in turn is
returned by StartImage().

Let the `bootefi` command print the exit data string in case of an error.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: memory leak in append value

When printing an UEFI variable an error may arise while converting an
illegal hexadecimal value. In this case a buffer is leaked.

Close the memory leak. Provide an error message.

Reported-by: Coverity (CID 185830)
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: optional data in load options are binary

The field boot OptionalData in structure _EFI_LOAD_OPTIONS is for binary
data.

When we use `efidebug boot add` we should convert the 5th argument from
UTF-8 to UTF-16 before putting it into the BootXXXX variable.

When printing boot variables with `efidebug boot dump` we should support
the OptionalData being arbitrary binary data. So let's dump the data as
hexadecimal values.

Here is an example session protocol:

=> efidebug boot add 00a1 label1 scsi 0:1 doit1 'my option'
=> efidebug boot add 00a2 label2 scsi 0:1 doit2
=> efidebug boot dump
Boot00A0:
  attributes: A-- (0x00000001)
  label: label1
  file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit1
  data:
    00000000: 6d 00 79 00 20 00 6f 00 70 00 74 00 69 00 6f 00  m.y. .o.p.t.i.o.
    00000010: 6e 00 00 00                                      n...
Boot00A1:
  attributes: A-- (0x00000001)
  label: label2
  file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit2
  data:

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

cmd: efidebug: rework "boot dump" sub-command using GetNextVariableName()

Currently in do_efi_boot_dump(), we directly read EFI variables from
related environment variables. To accommodate alternative storage
backends, we should switch to using the UEFI API instead.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: set OsIndicationsSupported at init

UEFI variables should be installed using well-defined API.
Currently we don't support much, but the value of OsIndicationsSupported
will be updated once some features are added in the future.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Add comments. Rename a variable.

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: FreePages() must fail with pages = 0

The UEFI spec requires that freeing of pages fails if the number of pages
to be freed is 'invalid'. Check that it is not zero.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: parameter check CreateEventEx()

CreateEvent() and CreateEventEx() should check that a notify function is
provided for either of EVT_NOTIFY_SIGNAL or EVT_NOTIFY_WAIT.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Merge tag 'rockchip-for-2019.07' of git://git.denx.de/u-boot-rockchip

Improvements and new features:
- improved SPI driver for better read throughput
- refactors initialisation of debug UART init
- restructures header file paths
- adds pinctrl improvements

Adds Kever as a co-custodian.

Merge tag 'u-boot-imx-20190426' of git://git.denx.de/u-boot-imx

Porting to DM and i.MX8
------------------------

- warp7 to DM
- kp_imx53 to DM
- Warnings in DT
- MX8QM support
- colibri-imx6ull to DM
- imx7d-pico to DM
- ocotp for MX8

rockchip: rk3288: include header for back_to_bootrom

To avoid a warning, we need to include the header defining
back_to_bootrom for us.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: rk3399: include gpio.h

After applying the series for debug_uart_init(), Travis-CI reports:

arch/arm/mach-rockchip/rk3399/rk3399.c:90:2: error: implicit declaration of function 'spl_gpio_set_pull' [-Werror=implicit-function-declaration]
  spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_B, 2), GPIO_PULL_NORMAL);
  ^~~~~~~~~~~~~~~~~

This is caused by a missing header-file include.  Fix it.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: rk3399: add board_debug_uart_init()

Use board_debug_uart_init() for UART iomux init instead of
do it in board_init_f, and move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file for all rockchip SoCs later.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: rk3399: use grf structure to access reg

Prefer to use structure to access register if we could.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: rk3368: move board_debug_uart_init() to rk3368.c

Move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file later for all rockchip SoCs.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: rk3288: add board_debug_uart_init()

Use board_debug_uart_init() for UART iomux init instead of
do it in board_init_f, and move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file for all rockchip SoCs later.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: rk3288: use grf structure to access soc_con2

Prefer to use structure to access register if we can.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: rk322x: move board_debug_uart_init() to rk322x.c

Move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file later for all rockchip SoCs.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
[Fixed up header-list to not break FASTBOOT:]
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: rk3188: add board_debug_uart_init()

Use board_debug_uart_init() for UART iomux init instead of
do it in board_init_f, and move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: rk3036: add board_debug_uart_init()

Use board_debug_uart_init() for UART iomux init instead of
do it in board_init_f, and move the function to soc file so
that we can find all the soc/board setting in soc file and
use a common board file.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
[Fixed whitespace error:]
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip; kylin-rk3036: enabl DEBUG UART

Enable debug uart for kylin board in defconfig.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: enable DEBUG_UART_BOARD_INIT by default

All Rockchip SoCs use DEBUG_UART_BOARD_INIT to init per board
UART IOMUX, enable it by default.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: correct ARCH_SOC name

The ARCH_SOC name default as 'rockchip' and we put all the
header file in 'arch/arm/include/asm/arch-rockchip/', but
the 'rockchip' is not the SOC name, let's correct it after
we update all the source file.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsiich <philipp.tomsich@theobroma-systems.com>

rockchip: use 'arch-rockchip' as header file path

Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common
header file path, so that we can get the correct path directly.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: arm: use 'arch-rockchip' for common header

rockchip platform header file is in 'arch-rockchip'
instead of arch-$(SOC) for all SoCs.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: add Kever Yang as co-custodian

This updates MAINTAINERS and git-mailrc to add me as a
co-custodian for rockchip

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Acked-by: Tom Rini <trini@konsulko.com>

rockchip: arm: remove no use macro

TIMER7_BASE is no used by source code now, remove it.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rk3288-board: remove pinctrl call for debug uart

This failed and caused a boot failure on c201, and afaik
the pins should be setup by the new pinctrl driver.

Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

pinctrl: exit pinconfig_post_bind if there are no subnodes

This fixes RK3288 SPL hanging or hitting this assert:
drivers/core/ofnode.c:183: ofnode_first_subnode: Assertion `ofnode_valid(node)' failed.

Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: rk3399: Add Orangepi RK3399 support

Add initial support for Orangepi RK3399 board.

Specification
- Rockchip RK3399
- 2GB/4GB DDR3
- 16GB eMMC
- SD card slot
- RTL8211E 1Gbps
- AP6356S WiFI/BT
- HDMI In/Out, DP, MIPI DSI/CSI
- Mini PCIe
- Sensors, Keys etc
- DC12V-2A and DC5V-2A

Commit details about Linux DTS sync:
"arm64: dts: rockchip: Add support for the Orange Pi RK3399"
(sha1: d3e71487a790979057c0fdbf32f85033639c16e6)

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi

u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
which is U-Boot specific devicetrees binding.

Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
bindings will move it future based on the requirement.

This would help to sync the devicetrees from Linux whenever required
instead of adding specific nodes.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: dts: rk3399: Sync rk3399-opp from Linux

Sync rk3399-opp.dtsi from Linux.

Linux commit details about the rk3399-opp.dtsi sync:
"arm64: dts: rockchip: use SPDX-License-Identifier"
(sha1: 4ee99cebd486238ac433da823b95cc5f8d8a6905)

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: spi: make optimised receive-handler unaligned-safe

To support unaligned output buffers (i.e. 'in' in the terminology of
the SPI framework), this change splits each 16bit FIFO element after
reading and writes them to memory in two 8bit transactions.  With this
change, we can now always use the optimised mode for receive-only
transcations independent on the alignment of the target buffer.

Given that we'll run with caches on, the impact should be negligible:
as expected, this has no adverse impact on throughput if running with
a 960MHz LPLL configuration.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: spi: add driver-data and a 'rxonly_manages_fifo' flag

The SPI controller's documentation (I only had access to the RK3399,
RK3368 and PX30 TRMs) specifies that, when operating in master-mode,
the controller will stop the SCLK to avoid RXFIFO overruns and TXFIFO
underruns.  Looks like my worries that we'd need to support DMA-330
(aka PL330) to make any further progress were unfounded.

This adds a driver-data structure to capture hardware-specific
settings of individual controller instances (after all, we don't know
if all versions are well-behaved) and adds a 'master_manages_fifo'
flag to it.  The first use of said flag is in the optimised
receive-only transfer-handler, which can now request 64Kframe
(i.e. 128KByte) bursts of data on each reprogramming of CTRLR1
(i.e. every time through the loop).

This improves throughput to 46.85MBit/s (a 94.65% bus-utilisation).

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: spi: add optimised receive-only implementation

For the RK3399-Q7 we recommend storing SPL and u-boot.itb in the
on-module 32MBit (and sometimes even larger, if requested as part of a
configure-to-order configuration) SPI-NOR flash that is clocked for a
bitrate of 49.5MBit/s and connected in a single-IO configuration (the
RK3399 only supports single-IO for SPI).

Unfortunately, the existing SPI driver is excruciatingly slow at
reading out large chunks of data (in fact it is just as slow for small
chunks of data, but the overheads of the driver-framework make it less
noticeable): before this change, the throughput on a 4MB read from
SPI-NOR is 8.47MBit/s which equates a 17.11% bus-utilisation.

To improve on this, this commit adds an optimised receive-only
transfer (i.e.: out == NULL) handler that hooks into the main transfer
function and processes data in 16bit frames (utilising the full with
of each FIFO element).  As of now, the receive-only handler requires
the in-buffer to be 16bit aligned.  Any lingering data (i.e. either if
the in-buffer was not 16-bit aligned or if an odd number of bytes are
to be received) will be handled by the original 8bit reader/wirter.

Given that the SPI controller's documentation does not guarantuee any
interlocking between the RXFIFO and the master SCLK, the transfer loop
will be restarted for each chunk of 32 frames (i.e. 64 bytes).

With this new receive-only transfer handler, the throughput for a 4MB
read increases to 36.28MBit/s (i.e. 73.29% bus-utilisation): this is a
4x improvement over the baseline.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reported-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-Cc: Klaus Goger <klaus.goger@theobroma-systems.com>
Series-Cc: Christoph Muellner <christoph.muellner@theobroma-systems.com>

rockchip: spi: only wait for completion, if transmitting

The logic in the main transmit loop took a bit of reading the TRM to
fully understand (due to silent assumptions based in internal logic):
the "wait until idle" at the end of each iteration through the loop is
required for the transmit-path as each clearing of the ENA register
(to update run-length in the CTRLR1 register) will implicitly flush
the FIFOs... transmisson can therefore not overlap loop iterations.

This change adds a comment to clarify the reason/need for waiting
until the controller becomes idle and wraps the entire check into an
'if (out)' to make it clear that this is required for transfers with a
transmit-component only (for transfers having a receive-component,
completion of the transmit-side is trivially ensured by having
received the correct number of bytes).

The change does not increase execution time measurably in any of my
tests.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: spi: consistently use false/true with rkspi_enable_chip

While rkspi_enable_chip is called with true/false everywhere else in
the file, one call site uses '0' to denot 'false'.
This change this one parameter to 'false' and effects consistency.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: spi: fix off-by-one in chunk size computation

The maximum transfer length (in a single transaction) for the Rockchip
SPI controller is 64Kframes (i.e. 0x10000 frames) of 8bit or 16bit
frames and is encoded as (num_frames - 1) in CTRLR1.  The existing
code subtracted the "minus 1" twice for a maximum transfer length of
0xffff (64K - 1) frames.

While this is not strictly an error (the existing code is correct, but
leads to a bit of head-scrating), fix this off-by-one situation.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: spi: remove unused code and fields in priv

Even though the priv-structure and the claim-bus function contain
logic for 16bit frames and for unidirectional transfer modes, neither
of these is used anywhere in the driver.

This removes the unused (as in "has no effect") logic and fields.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: spi: add debug message for delay in CS toggle

In analysing delays introduced for large SPI reads, the absence of any
indication when a delay was inserted (to ensure the CS toggling is
observed by devices) became apparent.

Add an additional debug-only debug message to record the insertion and
duration of any delay (note that the debug-message will cause a delay
on-top of the delay-duration).

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

rockchip: rk3399-puma: support Gigadevice SPI-NOR flash

Over the last quarter, a part of our production has used NOR flash
from Gigadevice in addition to the Winbond parts that we typically
source.  This requires the SPI_FLASH_GIGADEVICE config to be set.

Enable SPI_FLASH_GIGADEVICE in the board's default defconfig.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Klaus Goger <klaus.goger@theobroma-systems.com>

Prepare v2019.07-rc1

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

configs: move CONFIG_SPL_TEXT_BASE to Kconfig

Moved CONFIG_SPL_TEXT_BASE to common/spl/Kconfig and migrate existing
values.

Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
[trini: Re-run migration]
Signed-off-by: Tom Rini <trini@konsulko.com>

configs: Resync with savedefconfig

Rsync all defconfig files using moveconfig.py

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

dts: arm: socfpga: fix socfpga_de10_nano console

Booting this board failed as the initial console isn't found since
commit c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from linux")

The uart0 devicetree entry was missing "clock-frequency = <100000000>:"
since that commit

Fixes: c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from linux")
Reported-by: rafael mello <rafaelmello_3@hotmail.com>
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

The usage of socfpga_sdram_apply_static_cfg() seems rather dubious and
is confirmed to lead to a rare system hang when enabling bridges. This
patch removes the socfpga_sdram_apply_static_cfg() altogether, because
it's use seems unjustified and problematic.

The socfpga_sdram_apply_static_cfg() triggers write to SDRAM staticcfg
register to set the applycfg bit, which according to old vendor U-Boot
sources can only be written when there is no traffic between the SDRAM
controller and the rest of the system. Empirical measurements confirm
this, setting the applycfg bit when there is traffic between the SDRAM
controller and CPU leads to the SDRAM controller accesses being blocked
shortly after.

Altera originally solved this by moving the entire code which sets the
staticcfg register to OCRAM [1]. The commit message claims that the
applycfg bit needs to be set after write to fpgaportrst register. This
is however inverted by Altera shortly after in [2], where the order
becomes the exact opposite of what commit message [1] claims to be the
required order. The explanation points to a possible problem in AMP
use-case, where the FPGA might be sending transactions through the F2S
bridge.

However, the AMP is only the tip of the iceberg here. Any of the other
L2, L3 or L4 masters can trigger transactions to the SDRAM. It becomes
rather non-trivial to guarantee there are no transactions to the SDRAM
controller.

The SoCFPGA SDRAM driver always writes the applycfg bit in SPL. Thus,
writing the applycfg again in bridge enable code seems redundant and
can presumably be dropped.

[1] https://github.com/altera-opensource/u-boot-socfpga/commit/75905816ec95b0ccd515700b922628d7aa9036f8
[2] https://github.com/altera-opensource/u-boot-socfpga/commit/8ba6986b04a91d23c7adf529186b34c8d2967ad5

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>

mmc: dw_mmc: Round up descriptor end to nearest multiple of cacheline size

The driver currently calculates the end address of cache flush operation
for the DMA descriptors by adding cacheline size to the start address of
the last DMA descriptor. This is not safe, as the cacheline size may be,
in some unlikely cases, smaller than the DMA descriptor size. Replace the
addition with roundup() applied on the end address of the last DMA
descriptor to round it up to the nearest cacheline size multiple.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Simon Glass <sjg@chromium.org>

mmc: dw_mmc: Handle return value from bounce_buffer_start()

The bounce_buffer_start() can return -ENOMEM in case memory allocation
failed. However, in that case, the bounce buffer address is the same as
the possibly unaligned input address, and the cache maintenance operations
were not applied to this address. This could cause subtle problems. Add
handling for the bounce_buffer_start() return value to prevent such a
problem from happening.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Simon Glass <sjg@chromium.org>

mmc: dw_mmc: Calculate timeout from transfer length

The current 4-minute data transfer timeout is misleading and broken.
Instead of such a long wait, calculate the timeout duration based on
the length of the data transfer. The current formula is the transfer
length in bits, divided by a multiplication of bus frequency in Hz,
bus width, DDR mode and converted the mSec. The value is bounded from
the bottom to 1000 mSec.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Simon Glass <sjg@chromium.org>