lbc_clk is used to fixup dts as "bus frequency".
It is not being used by Linux IFC and eLBC driver.

So remove unused "bus frqeuency" fix-up of devicre tree.

Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

PBL flush command is restricted to CCSR memory space. So use WAIT
PBI command to provide enough time for data to get flush in
target memory.

Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
[York Sun: rewrap commit message]
Reviewed-by: York Sun <york.sun@nxp.com>

T series boards use unified RCW for sd, spi and nand boot.
Now split txxx_rcw.cfg to txxx_sd_rcw.cfg, txxx_spi_rcw.cfg
and txxx_nand_rcw.cfg for SPI/NAND/SD boot.
And modify RCW[PBI_SRC] for them:
	PBI_SRC=5            for SPI 24-bit addressing
	PBI_SRC=6            for SD boot
	PBI_SRC=14           for IFC NAND boot

Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>

eth-uclass.c expects DM-capable Ethernet adapters to implement ops->
read_rom_hwaddr(), or for some other mechanism to set pdata->enetaddr, or
for the user to set environment variable $usbethaddr. Without any of
these, it will refuse to initialize the device since no valid MAC address
is known. Implement this function for the smsc95xx driver.

With this feature implemented, there is no point smsc95xx_init_common()
re-reading the MAC address from ROM, so ifdef out this code when DM_ETH
is enabled.

This allows (at least) the built-in Ethernet on the NVIDIA Harmony board
to operate again.

Fixes: 0990fcb7 ("net: smsc95xx: Add driver-model support")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

Add a NFS download test, based on TFTP test.
Tested on i.MX6 SabreLite board.

Signed-off-by: Guillaume GARDET <guillaume.gardet@free.fr>

Cc: Tom Rini <trini@konsulko.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

After any operation that downloads a file (e.g., pxe get, or dhcp), the
buffer containing the downloaded data is flushed.  This is unnecessary
and annoying.  Unnecessary, because
the network driver should already have fliushed the cache for the DMAed area,
and annoying because it generates a cache misalignment message.

Signed-off-by: Peter Chubb <peter.chubb@data61.csiro.au>
Acked-by: Heiko Schocher <hs@denx.de>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

The call to flush cache on the transmit buffer was misplaced (for very
short packets) and asked to flush less than a cacheline.

Move the flush cache call to after a short packet has been padded
to minimum length (so the padding is flushed too), and round the size
up to a cacheline.

Signed-off-by: Peter Chubb <peter.chubb@data61.csiro.au>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

If mac-address is changed using "setenv ethaddr ...." command the new
mac-adress also must be written into the responsible ethernet driver.

Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

Signed-off-by: Chris Packham <judge.packham@gmail.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

On some boards these switches are wired directly into a SERDES
interface on another Ethernet MAC. Add the ability to specify
these kinds of boards using CONFIG_MV88E61XX_FIXED_PORTS which defines
a bit mask of these fixed ports.

Signed-off-by: Chris Packham <judge.packham@gmail.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

The Marvell Link Street mv88e60xx is a series of FastEthernet switch
chips, some of which also support Gigabit ports. It is similar to the
mv88e61xx series which support Gigabit on all ports.

The main difference is the number of ports. Which affects the
PORT_COUNT define and the size of the mask passed to
mv88e61xx_port_set_vlan().

Other than that it's just a matter of adding the appropriate chip
IDs.

Signed-off-by: Chris Packham <judge.packham@gmail.com>
Cc: Joshua Scott <joshua.scott@alliedtelesis.co.nz>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

Ethernet ports might be used in the kernel even if CPSW driver
is disabled at u-boot. So always set ethaddr and eth1addr
environment variable from efuse.

Retain usbnet_devaddr as it is required for SPL USB eth boot.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

Both ethernet ports can be used as CPSW ethernet (RMII mode)
or PRU ethernet (MII mode) by setting the jumper near the port.
Read the jumper value and set the pinmux, external mux and
PHY clock accordingly.

As jumper line is overridden by PHY RX_DV pin immediately
after bootstrap (power-up/reset), we have to use GPIO edge
detection to capture the jumper line status.

As u-boot doesn't provide any infrastructure for GPIO edge
detection, we directly access the GPIO registers.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

cpsw driver supports only selection of phy mode in control module
but control module has more setting like RGMII ID mode selection,
RMII clock source selection. So ported to cpsw-phy-sel driver
from kernel to u-boot.

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

In AM335x GP EVM, Atheros 8031 phy is used, enable the driver as
AM335x SoC RGMII delay mode has to be enabled in phy as mentioned
in the silicon errata Advisory 1.0.10

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

In the current driver implementation, config() callback is common
for AR8035 and AR8031 phy. In config() callback, driver tries to
configure MMD Access Control Register and MMD Access Address Data
Register unconditionally for both phy versions which leads to
auto negotiation failure in AM335x EVMsk second port which uses
AR8031 Giga bit RGMII phy. Fixing this by adding separate config
for AR8031 phy.

Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

This adds support for internal delay on RX and TX on RGMII interface for the
AR8035 phy.

This is basically the same Linux driver do. Tested on a Zynq Zturn board (for
which u-boot support in is my tree; first patch waiting ML approval)

Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

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

Conflicts:
	include/configs/ls1021aqds.h
	include/configs/ls1021atwr.h

Create a Kconfig entry for DISPLAY_BOARDINFO and make it be the default
in certain architectures.  Migrate all config files.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

Create a Kconfig entry for DISPLAY_CPUINFO and make it be the default
in certain architectures.  Migrate all config files.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

Legacy video driver macros are not needed. Clean them up.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Now that all x86 boards have been converted to DM video, drop the
legacy drivers.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

This converts coreboot to use DM framebuffer driver.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

With DM VESA driver on x86 boards, plat->base/size/align are all
zeroes and starting address passed to alloc_fb() happens to be 1MB
aligned, so this routine does not trigger any issue. On QEMU with
U-Boot as coreboot payload, the starting address is within 1MB
range (eg: 0x7fb0000), thus causes failure in video_post_bind().

Actually if plat->size is zero, it makes no sense to do anything
in this routine. Add such check there.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

This adds a DM driver for coreboot framebuffer device.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

vbe_setup_video_priv() might be useful to other drivers.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The kernel load address for zboot should be 0x1000000.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

At present only chromebook boards are converted to DM video. Other
x86 boards are still using the legacy cfb_console driver. This
switches to use DM version drivers.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

With DM conversion, information like "Video: 1024x768x16" is not
shown anymore. Now add these verbose output back.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

This adds a DM driver for VESA-compatible device.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

For some unknown reason, coreboot framebuffer driver never works on
QEMU since day 1. It seems the driver only works on real hardware.
Document this issue.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Move crosec commands from drivers/misc/cros_ec.c to
cmd/cros_ec.c

Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Miao Yan <yanmiaobest@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: u-boot@lists.denx.de