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

The two functions are now exactly the same, remove one of them.
Signed-off-by: NMichael Walle <michael@walle.cc>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

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>

Add support for configuring the CLK_25M pin as well as the RGMII I/O
voltage by the device tree.

By default the AT803x PHYs outputs the 25MHz clock of the XTAL input.
But this output can also be changed by software to other frequencies.
This commit introduces a generic way to configure this output.

Also the PHY supports different RGMII I/O voltages: 1.5V, 1.8V and 2.5V.
An internal LDO is able to provide 1.5V (default) and 1.8V. The 2.5V
option needs an external supply voltage. This commit adds support to
switch the internal LDO to 1.8V.
Signed-off-by: NMichael Walle <michael@walle.cc>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Signed-off-by: NMichael Walle <michael@walle.cc>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Provide functions to read and write the Atheros debug registers.
Signed-off-by: NMichael Walle <michael@walle.cc>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Signed-off-by: NMichael Walle <michael@walle.cc>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

The upper bits are all the OUI.
Signed-off-by: NMichael Walle <michael@walle.cc>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Debug register 5 contains TX_CLK DELAY at bit 8 and reserved values at
the other bit positions, just like the other PHYs in the family do.
Therefore, it is not necessary to hardcode the reserved values, but
instead simply follow the read-modify-write procedure from the common
function.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

To eliminate any doubts about the out-of-reset value of the PHY, that
the driver previously relied on.

If bisecting shows that this commit breaks your board you probably have
a wrong PHY interface mode. You probably want the
PHY_INTERFACE_MODE_RGMII_RXID or PHY_INTERFACE_MODE_RGMII_ID mode.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Also take the opportunity to use the phy_read_mmd and phy_write_mmd
convenience functions.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Delete the extraneous write to debug reg 5 that enables Tx delay

When the driver was originally introduced in commit "6027384a phylib:
Add Atheros AR8035 GETH PHY support", the Tx delay was being
unconditionally enabled.

Then during "2ec4d10b phy: atheros: add support for RGMII_ID, RGMII_TXID
and RGMII_RXID", the author did not notice that code for enabling Tx
delay code was already. Therefore, the if condition for Tx delay has
always been useless for this PHY since this commit introduced it.

Prior to this patch, every AR8035 PHY in U-boot had Tx delay enabled.
After this patch, only those who define the interface as RGMII_TXID or
RGMII_ID will. This is to be expected, but will nonetheless break the
setups of those who didn't know they rely on Tx delay implicitly.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

- ARM Juno updates
- Assorted bugfixes

Currently displaying status line is done in a weak function
menu_display_statusline().

bootmenu.c overrides the weak default function.
It calls menu_default_choice() and interprets the data as
struct bootmenu_entry.

pxe boot also uses common menu code for pxe menus.
If there is a system that enables both bootmenu and pxe,
menu_display_statusline() defined in bootmenu.c will be called
and it will interpret struct pxe_label as struct bootmenu_entry.
This leads to data aborts and pxe menu corruptions.

This patch adds support for client defined statusline function
to resolve the above bug.
Signed-off-by: NThirupathaiah Annapureddy <thiruan@linux.microsoft.com>

To fill the exponent field of the rsa_public_key struct, rsa_mod_exp_sw
did a cast to uint64_t of the key_prop->public_exponent field.
But that alignment is not guaranteed in all cases.

This came to light when in my spl-fit-signature the key-name exceeded
a certain length and with it the verification then started failing.
(naming it "integrity" worked fine, "integrity-uboot" failed)

key_prop.public_exponent itself is actually a void-pointer, fdt_getprop()
also just returns such a void-pointer and inside the devicetree the 64bit
exponent is represented as 2 32bit numbers, so assuming a 64bit alignment
can lead to false reads.

So just use the already existing rsa_convert_big_endian() to do the actual
conversion from the dt's big-endian to the needed uint64 value.

Fixes: fc2f4246 ("rsa: Split the rsa-verify to separate the modular exponentiation")
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

If dcache is switched OFF to ON state and if non-cached memory is
used, this non-cached memory must be re-declared as uncached to mmu
each time dcache is set ON.

Introduce noncached_set_region() to set this non-cached region's mmu
settings. Let architecture override it by defining it as a weak
function.

For ARM architecture, noncached_set_region() defines all noncached
region as non-cacheable.

Issue found on STM32MP1 platform using dwc_eth_qos ethernet driver,
when going from dcache OFF to dcache ON state, ethernet driver issued
TX timeout errors when performing dhcp or ping.

It can be reproduced with the following sequence:

dhcp
while true ; do
  ping 192.168.1.300 ;
  dcache off ;
  ping 192.168.1.300 ;
  dcache on ;
done
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Cc: Stephen Warren <swarren@nvidia.com>
Reviewed-by: NMarek Vasut <marex@denx.de>

CONFIG_SEMIHOSTING is selected for the VFP target by the means of
Kconfig already, there is no need to check this in the header file.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The Juno board features a standard compliant EHCI/OHCI USB host
controller pair, which we can just enable.
The platform data is taken from the device tree.

This allows to use USB mass storage (the only storage on a Juno r0)
for loading.

At least on my board USB seems a bit flaky, I need two "usb reset"
sequences after the "usb start" to detect an USB hard drive.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>

So far the Juno board wasn't implementing reset. Let's just use the
already existing PSCI_RESET based method to avoid any extra code.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The Arm Juno board was still somewhat stuck in "hardcoded land", even
though there are stable DTs around, and one happens to actually be on
the memory mapped NOR flash.

Enable the configuration options to let the board use OF_CONTROL, and
add a routine to find the address of the DTB partition in NOR
flash, to use that for U-Boot's own purposes.
This can also passed on via $fdtcontroladdr to any kernel or EFI
application, removing the need to actually load a device tree.

Since the existing "afs" command and its flash routines require
flash_init() to be called before being usable, and this is done much
later in the boot process, we introduce a stripped-down partition finder
routine in vexpress64.c, to scan the NOR flash partitions for the
DT partition. This location is then used for U-Boot to find and probe
devices.

The name of the partition can be configured, if needed, but defaults
to "board.dtb", which is used by Linaro's firmware image provided.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The UART base clock rate was typo-ed in the header file, probably because
the reference (the Linux .dts) was also wrong[1].

Fix the number to make the baud rate more correct.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39a1a8941b2Reviewed-by: NSimon Glass <sjg@chromium.org>

Even though the PL011 UART driver claims to be DM compliant, it does not
really a good job with parsing DT nodes. U-Boot seems to adhere to a
non-standard binding, either requiring to have a "skip-init" property in
the node, or to have an extra "clock" property holding the base
*frequency* value for the baud rate generator.
DTs in the U-Boot tree seem to have been hacked to match this
requirement.

The official binding does not mention any of these properties, instead
recommends a standard "clocks" property to point to the baud base clock.

Some boards use simple "fixed-clock" providers, which U-Boot readily
supports, so let's add some simple DM clock code to the PL011 driver to
learn the rate of the first clock, as described by the official binding.

These clock nodes seem to be not ready very early in the boot process,
so provide a fallback value, by re-using the already existing
CONFIG_PL011_CLOCK variable.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
[trini: Add <clock_legacy.h> for get_bus_freq() for layerscape
platforms]
Signed-off-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The U-Boot documentation explains that variables ending with "_r" hold
addresses in DRAM, while those without that ending point to flash/ROM.
The default variables for the Juno board pointing to the kernel and DTB
load addresses were not complying with this scheme: they lack the
extension, but point to DRAM. This is particularly confusing since the
Juno board features parallel NOR flash, so there *is* a memory mapped
NOR address holding a DTB, for instance.

Fix the variables to use the proper names, changing initrd_addr to
ramdisk_addr_r on the way, which seems to be more prevelant and
documented. On the way adjust the FDT load address to be situated
*before* the kernel, since users happened to overwrite the DTB by the
kernel clearing its .BSS section during initialisation.
Also remove the fdt_high and initrd_high variables (which were set
to -1), to allow U-Boot moving those images around.

This should avoid many problems in the future, but breaks loading
Linux kernels < v4.2, since they expect the DTB to be loaded in the same
512MB region as the kernel. If you need to load such an old kernel,
please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
load the kernel to the beginning of DRAM).

That fixes loading debug kernels, which happened to overwrite the DTB on
certain setups.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

CMD_EEPROM and ENV_IS_IN_EEPROM can be selected independently, and
cmd/eeprom.o gets built in either case, so whether to declare the real
prototypes needs to follow the same logic as whether cmd/eeprom.c is
built. Otherwise a ENV_IS_IN_EEPROM=y, CMD_EEPROM=n build fails

cmd/eeprom.c:73:1: error: expected identifier or ‘(’ before ‘{’ token
 {

While at it, fix the dummy replacements (at least assuming they are
meant to allow the code to compile) - they need to have the same type
as the expression they replace, or one gets errors such as

env/eeprom.c: In function ‘eeprom_bus_read’:
env/eeprom.c:37:8: error: void value not ignored as it ought to be
  rcode = eeprom_read(dev_addr, offset, buffer, cnt);
Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: NTom Rini <trini@konsulko.com>

This has been reported to break booting of U-Boot from SPL on a number
of platforms due to a lack of alignment of the external data.  The
issues this commit is addressing will need to be resolved another way.

Re-introduce a data leak in the padding for now.

This reverts commit 20a154f9.
Reported-by: NAlex Kiernan <alex.kiernan@gmail.com>
Reported-by: NMichael Walle <michael@walle.cc>
Tested-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NTom Rini <trini@konsulko.com>

In commit f62782fb ("cache: l2x0: Fix write to incorrect shared-override
bit") we removed writel to regs->pl310_aux_ctrl by accident.  This
commit restores it back.

Fixes: f62782fb ("cache: l2x0: Fix write to incorrect shared-override bit")
Signed-off-by: NLey Foon Tan <ley.foon.tan@intel.com>

It's possible that the default_environment[] array contains multiple
entries for the same variable, e.g. a setting from env_default.h based
on some CONFIG_* variable, and another from
CONFIG_EXTRA_ENV_SETTINGS. In such a case, the last setting takes
effect.

Hence, in order to be able to use the output from this script as an
CONFIG_DEFAULT_ENV_FILE and get the same default environment as one
currently has, we need to preserve the order. So only sort by the
variable name, and disable the last-resort comparison.

We could pipe the result through uniq to remove duplicate lines, but I
think there's some value in seeing that certain variables are defined
multiple times.
Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: NLukasz Majewski <lukma@denx.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>

- MediaTek USB host support

Pull request for UEFI sub-system for efi-2020-07-rc2-2

This patch contains error corrections and code simplifications for the UEFI
sub-system.

- Add DM model for P1010RDB
- Add I2C DM Model support for P1010RDB, T1042RDB, T2080, T4240RDB,
  MPC8548CDS, T1024RDB, P4080, P3041DS, P2041RDB, P2020RDB, P1020RDB,
  P5040DS
- Fix reference to READM.qe_firmware

- Support 64-bit U-Boot as the payload for coreboot x86

- 2 MVEBU related fixes

i.MX for 2020.07
----------------

- imxrt: fix LCD clock, fix doc
- new board: Coral Dev
- imx8: enable Cache in SPL. SNVS, update SCFW API
- imx8MM: fix reset, 8MQ quand and QuadLite, CPU speed grading
- MX6ULL : is_imx6ull to include i.MX6ULZ
- Net: add config to enable TXC delay

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

Commit 69529c91 ("net: pcnet: Switch to PCI memory access")
switched from PCI IO access to PCI memory access without updating
the I/O primitives. Contrary to SH, the primitives for memory
access and IO access are implemented differently. Thus doing
memory access with IO port primitives breaks the driver on
MIPS Malta board.
Signed-off-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

- dts clean up to use -u-boot for px30, rk3399 boards
- dts sycn from upstream kernel for rk3328, rk3399
- add rockchip rng driver
- new board support: rk3328-roc-cc, rk3399-roc-pc,Nanopi M4 2GB

This is part 1 of big network cleanup / DM conversion.
The dc2114x/rtl8139/pcnet/tulip PCI adapter drivers received checkpatch
cleanups in preparation for DM conversion. The smc911x is converted to
DM completely. The dwc_eth_qos cache fixes are applied.

There is no reason to tail-pad fitImage with external data to 4-bytes,
while fitImage without external data does not have any such padding and
is often unaligned. DT spec also does not mandate any such padding.

Moreover, the tail-pad fills the last few bytes with uninitialized data,
which could lead to a potential information leak.

$ echo -n xy > /tmp/data ; \
	./tools/mkimage -E -f auto -d /tmp/data /tmp/fitImage ; \
	hexdump -vC /tmp/fitImage | tail -n 3

before:
00000260  61 2d 6f 66 66 73 65 74  00 64 61 74 61 2d 73 69  |a-offset.data-si|
00000270  7a 65 00 00 78 79 64 64                           |ze..xydd|
                   ^^       ^^ ^^
after:
00000260  61 2d 6f 66 66 73 65 74  00 64 61 74 61 2d 73 69  |a-offset.data-si|
00000270  7a 65 00 78 79                                    |ze.xy|
Signed-off-by: NMarek Vasut <marex@denx.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Tom Rini <trini@konsulko.com>

If we want to restore variables from disk, we need to initialize block
devices before variables.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>