- rk3188 cpu init and APLL fix;
- rk3399: Add BOOTENV_SF command;
- rk3288 correct vop0 vop1 setting;

The EDP_LCDC_SEL bit has to be set correctly to select vop0 or
vop1, but so far we have set it in both conditions, which is not
correct.

Can someone verify this is the correct way round?  vop1 -> set,
vop0 -> clear?
Signed-off-by: NPatrick Wildt <patrick@blueri.se>
Reviewed-by: NKever Yang <kever.yang@rock-chips.com>

The commit 84a6a27a ("rockchip: rk3188: init CPU freq in clock
driver") changed ARM clock from 600MHz to 1600MHz. It made boot
unstable due to the fact that PMIC at the start generates insufficient
voltage for operation. See also: commit f4f57c58 ("rockchip:
rk3188: Setup the armclk in spl").

Fixes commit 84a6a27a ("rockchip: rk3188: init CPU freq in clock
driver").
Signed-off-by: NAlexander Kochetkov <al.kochet@gmail.com>
Reviewed-by: NKever Yang <kever.yang@rock-chips.com>

Move the setting for noc remap out of SPL code. Changing
noc remap inside SPL results in breaking back to BROM
boot.

Fixes commit c14fe2a8 ("rockchip: rk3188: Move SoC
one time setting into arch_cpu_init()").
Signed-off-by: NAlexander Kochetkov <al.kochet@gmail.com>
Reviewed-by: NKever Yang <kever.yang@rock-chips.com>

Add missing BOOTENV_SF command in rk3399 config.

Fix it.

Fixes: f263b860 ("rk3399: Enable SF distro bootcmd")
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Reported-by: NSuniel Mahesh <sunil@amarulasolutions.com>
Tested-by: NSuniel Mahesh <sunil@amarulasolutions.com>
Reviewed-by: NKever Yang <kever.yang@rock-chips.com>

- arm: socfpga: misc_s10: Fix EMAC register address calculation

Fix EMAC register address calculation, address need to multiply
with sizeof(u32) or 4.

This fixes write to invalid address.
Signed-off-by: NLey Foon Tan <ley.foon.tan@intel.com>

Pull request for UEFI sub-system for efi-2020-07-rc6

Corrections for variable definitions are provided:

* Correct size of secure boot related UEFI variables.
* Do not use int for storing an enum.
* Replace fdt_addr by fdt_size where needed.

Since commit:

commit 6333cbb3
Author: Michael Walle <michael@walle.cc>
Date:   Thu May 7 00:11:58 2020 +0200

    phy: atheros: ar8035: remove static clock config

    We can configure the clock output in the device tree. Disable the
    hardcoded one in here. This is highly board-specific and should have
    never been enabled in the PHY driver.

    If bisecting shows that this commit breaks your board it probably
    depends on the clock output of your Atheros AR8035 PHY. Please have a
    look at doc/device-tree-bindings/net/phy/atheros.txt. You need to set
    "clk-out-frequency = <125000000>" because that value was the hardcoded
    value until this commit.
Signed-off-by: NMichael Walle <michael@walle.cc>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

, the clock output setting for the AR803x driver is removed from being
hardcoded in the PHY driver and should be passed via device tree instead.

Update the device tree with the "qca,clk-out-frequency" property so that
Ethernet can work again.
Reported-by: NSoeren Moch <smoch@web.de>
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Tested-by: NSoeren Moch <smoch@web.de>

The variables SetupMode, AuditMode, DeployedMode are explicitly defined as
UINT8 in the UEFI specification. The type of SecureBoot is UINT8 in EDK2.

Use variable name secure_boot instead of sec_boot for the value of the
UEFI variable SecureBoot.

Avoid abbreviations in function descriptions.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Variable efi_secure_mode is meant to hold a value of enum efi_secure_mode.
So it should not be defined as int but as enum efi_secure_mode.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Variable fdt_size should be of type 'fdt_size_t', not 'fdt_addr_t'.

Fixes 0d7c2913: ("cmd: bootefi: Honor the address & size cells properties correctly")
Signed-off-by: NBin Meng <bin.meng@windriver.com>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

- Fix fsl_esdhc_imx tunning mask
- Disable CMD CRC for normal tuning for fsl_esdhc_imx
- Retry CM1 until emmc ready
- Fix sdhci HISPD handling
- Cache-aligned extcsd reading

SDHCI HISPD bits need to be configured based on desired mmc
timings mode and some HISPD quirks.

So, handle the HISPD bit based on the mmc computed selected
mode(timing parameter) rather than fixed mmc card clock
frequency.

Linux handle the HISPD similar like this in below commit but no
SDHCI_QUIRK_BROKEN_HISPD_MODE,

commit <501639bf2173> ("mmc: sdhci: fix SDHCI_QUIRK_NO_HISPD_BIT handling")

This eventually fixed the mmc write issue observed in
rk3399 sdhci controller.

Bug log for refernece,
=> gpt write mmc 0 $partitions
Writing GPT: mmc write failed
** Can't write to device 0 **
** Can't write to device 0 **
error!

Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Peng Fan <peng.fan@nxp.com>
Peng Fan: added back "ctrl &= ~SDHCI_CTRL_HISPD;" per Jaehoon's suggestion
Tested-by: Suniel Mahesh <sunil@amarulasolutions.com> # roc-rk3399-pc
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>

According to eMMC specification v5.1 section 6.4.3, we should issue
CMD1 repeatedly in the idle state until the eMMC is ready even if
mmc_send_op_cond() send CMD1 with argument = 0. Otherwise some eMMC
devices seems to enter the inactive mode after mmc_complete_op_cond()
issued CMD0 when the eMMC device is busy.
Signed-off-by: NHaibo Chen <haibo.chen@nxp.com>
Reviewed-by: NPeng Fan <peng.fan@nxp.com>

In current code, we add 1ms dealy after each tuning command for standard
tuning method. Adding this 1ms dealy is because USDHC default check the
CMD CRC and DATA line. If detect the CMD CRC, USDHC standard tuning
IC logic do not wait for the tuning data sending out by the card, trigger
the buffer read ready interrupt immediately, and step to next cycle. So
when next time the new tuning command send out by USDHC, card may still
not send out the tuning data of the upper command，then some eMMC cards
may stuck, can't response to any command, block the whole tuning procedure.

If do not check the CMD CRC for tuning, then do not has this issue. USDHC
will wait for the tuning data of each tuning command and check them. If the
tuning data pass the check, it also means the CMD line also okay for tuning.

So this patch disable the CMD CRC check for tuning, save some time for the
whole tuning procedure.
Signed-off-by: NHaibo Chen <haibo.chen@nxp.com>

According the RM, the bit[6~0] of register ESDHC_TUNING_CTRL is
TUNING_START_TAP, bit[7] of this register is to disable the command
CRC check for standard tuning. So fix it here.

Fixes: fa33d207 ("mmc: split fsl_esdhc driver for i.MX")
Signed-off-by: NHaibo Chen <haibo.chen@nxp.com>

The extcsd read target must be cache aligned in case the controller
uses DMA to read the extcsd register, make it so.
Signed-off-by: NMarek Vasut <marex@denx.de>
Reviewed-by: NMichael Trimarchi <michael@amarulasolutions.com>

- Assorted minor fixes

Avoid potential multiple definitions when CONFIG_ARM_PSCI_FW
is disabled.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Signed-off-by: NVagrant Cascadian <vagrant@debian.org>

Signed-off-by: NVagrant Cascadian <vagrant@debian.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This patch try to avoids eviction of dirty lines during DMA
transfer. The code right now execute the following step:

- allocate the buffer
- start a dma operation using the non-coherent dma buffer
- invalidate cache lines associated with the buffer
- read the buffer

This can lead to reading back not valid information, because the cache
controller could evict dirty cache lines belonging to the buffer *after*
the DMA operation has started to fill the DRAM.
In order to avoid this, a new invalidation is required *before* starting
the DMA operation. The patch just adds an invalidation before submitting
the DMA command.

Example below shows the nvme disk scan result without the following
patch

=> nvme scan
nvme_get_info_from_identify: nn = 544502629, vwc = 100,
sn = dev_0T, mn = `�\�, fr = t_part, mdts = 105

So, invalidating the cache before submitting the admin command,
fix the cpu read.

Cc: André Przywara <andre.przywara@arm.com>
Reported-by: NSuniel Mahesh <sunil@amarulasolutions.com>
Signed-off-by: NMichael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Tested-by: NSuniel Mahesh <sunil@amarulasolutions.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

The correct name for the property is "qca,clk-out-frequency", so fix
it accordingly.
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Reviewed-by: NMichael Walle <michael@walle.cc>

Commit 0528979f ("part: Drop disk_partition_t typedef") changed to
a struct. As a result it uncovered an apparent missing include in
zfs_common.h for part.h which actually contains the definition. The ZFS
handles the struct exclusively as pointers so it was only a warning.

    warning: ‘struct disk_partition’ declared inside parameter list
    will not be visible outside of this definition or declaration
 void zfs_set_blk_dev(struct blk_desc *rbdd, struct disk_partition *info);
Signed-off-by: NJoel Johnson <mrjoel@lixil.net>

Series-CC: Simon Glass <sjg@chromium.org>

Fixes for 2020.07
-----------------

Travis: https://travis-ci.org/github/sbabic/u-boot-imx/builds/701059103

- Fixes for atheros and cubox
- Toradex: mostly environment
- i.MX7: DDR fixes
- switch to DM
- sabrelite : fix MMC access

Rsync all defconfig files using moveconfig.py
Signed-off-by: NTom Rini <trini@konsulko.com>

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

After enabling SPL_OF_CONTROL, SPL_DM and SPL_DM_MMC the MMC
initialization code is not longer needed.

This patch removes the unused code.
Signed-off-by: NWalter Lozano <walter.lozano@collabora.com>

In order to take the beneficts of DT and DM in SPL, like reusing the code
and avoid redundancy, enable SPL_OF_CONTROL, SPL_DM and SPL_DM_MMC.

With this new configuration SPL image is 50 KB, higher than the
38 KB from the previous version, but it still under the 68 KB limit.
Signed-off-by: NWalter Lozano <walter.lozano@collabora.com>

In SPL legacy code only one MMC device is created, based on BOOT_CFG
register, which can be either SD or eMMC. In this context
board_boot_order return always MMC1 when configure to boot from
SD/eMMC. After switching to DM both SD and eMMC devices are created
based on the information available on DT, but as board_boot_order
only returns MMC1 is not possible to boot from eMMC.

This patch customizes board_boot_order taking into account BOOT_CFG
register to point to correct MMC1 / MMC2 device. Additionally, handle
IO mux for the desired boot device.
Signed-off-by: NWalter Lozano <walter.lozano@collabora.com>

Signed-off-by: NWalter Lozano <walter.lozano@collabora.com>

Convert to DM_ETH to avoid board removal from the project.
Signed-off-by: NFabio Estevam <festevam@gmail.com>

Convert to DM_ETH to avoid board removal from the project.
Signed-off-by: NFabio Estevam <festevam@gmail.com>

Convert to DM_ETH to avoid board removal from the project.
Signed-off-by: NFabio Estevam <festevam@gmail.com>

Current aliases missed gpio0 node, and this node shoud be
aliased to gpio index 0 to align with i.MX8QXP. Otherwise, we
will get below message when running "gpio status" command, and
see the reason by "dm uclass".

=> gpio status
Device 'gpio@5d090000': seq 0 is in use by 'gpio@5d080000'
Device 'gpio@5d0a0000': seq 1 is in use by 'gpio@5d090000'
Device 'gpio@5d0b0000': seq 2 is in use by 'gpio@5d0a0000'

=> dm uclass
uclass 36: gpio
0   * gpio@5d080000 @ fbaefb90, seq 0, (req -1)
1   * gpio@5d090000 @ fbaefc70, seq 1, (req 0)
2   * gpio@5d0a0000 @ fbaefd50, seq 2, (req 1)
3   * gpio@5d0b0000 @ fbaefe30, seq 5, (req 2)
4   * gpio@5d0c0000 @ fbaeff10, seq 3, (req 3)
5   * gpio@5d0d0000 @ fbaefff0, seq 4, (req 4)
6   * gpio@5d0e0000 @ fbaf00d0, seq 6, (req 5)
7   * gpio@5d0f0000 @ fbaf01b0, seq 7, (req 6)
Signed-off-by: NYe Li <ye.li@nxp.com>

Since the i.MX8 GPIO banks are indexed from 0 not 1 on other i.MX
platforms, so we have to adjust the index accordingly.
Signed-off-by: NAdrian Alonso <adrian.alonso@nxp.com>
Signed-off-by: NYe Li <ye.li@nxp.com>

We need to change the environment offset to avoid corrupting the U-Boot
binary when saving it.
Signed-off-by: NOtavio Salvador <otavio@ossystems.com.br>
Reviewed-by: NFabio Estevam <festevam@gmail.com>

This fixes the boot from USB loader, which is critical to easy the
manufacture process.
Signed-off-by: NOtavio Salvador <otavio@ossystems.com.br>
Reviewed-by: NFabio Estevam <festevam@gmail.com>

Select default U-Boot and SPL text base for the MX7 SoC. The U-Boot
text base is picked as the one used by various MX7 boards. The SPL
text base however is different.

The SPL text base is set to 0x912000 instead of the usual 0x911000,
that is because the 0x911000 value cannot work. Using 0x911000 as a
SPL text base will result in the DCD header being placed below the
0x911000 address, which is a reserved SRAM area which must not be
used. This will actually trigger eMMC boot failure on MX7D at least.
Hence the increment.

Update all boards affected by this SPL problem to the new SPL_TEXT_BASE.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP i.MX U-Boot Team <uboot-imx@nxp.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>