arm64: mvebu: a8k: autodetect RAM size

Some Armada 8K boards like Macchiatobin and Clearfog GT-8K use RAM from
external DIMM. Hard coding the RAM size in the device-tree is not
convenient. Fortunately, the ATF that initializes the RAM knows the size
of RAM, and U-Boot can query the ATF using a SMC call.

The ATF maps the lower 3G of RAM starting at address 0. Higher RAM is
mapped at 4G. This leaves a 1G hole between 3G and 4G for IO
peripherals. Use a second bi_dram[] entry to describe the higher RAM
area. As a result, CONFIG_NR_DRAM_BANKS must be set to 2 to use more
than 3GB RAM.

This code in this commit is mostly taken from downstream Marvell U-Boot
code by Grzegorz Jaszczyk.

Cc: Grzegorz Jaszczyk <jaz@semihalf.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Stefan Roese <sr@denx.de>

linux/sizes.h: sync from kernel

The kernel added SZ_4G macro in commit f2b9ba871b (arm64/kernel: kaslr:
reduce module randomization range to 4 GB).

Include linux/const.h for the _AC macro.

Drop a local SZ_4G definition in tegra code.

Cc: Tom Warren <twarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Stefan Roese <sr@denx.de>

MIPS: drop asm/const.h

Commit 86f21c96f467368 (mips: Use common _AC macro now.) removed the _AC
definition from const.h. All other macros defined in const.h are not
used anywhere, and there is now no user of this header. Remove this
header.

Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>

Use _AC and UL macros from linux/const.h

Drop the _AC and UL macros from common.h. Linux headers is the original
source of this macro, so keep its definition in the same header.

Update existing users of these macros to include const.h directly.

Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Rick Chen <rick@andestech.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Rick Chen <rick@andestech.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>

linux/const.h: import from kernel

Combine the uapi/linux/const.h header into the kernel linux/const.h. The
next commit will use the _AC macro this header instead of the common.h
definition.

Based on Linux kernel version 4.19.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Stefan Roese <sr@denx.de>

Merge tag 'mips-pull-2018-11-18' of git://git.denx.de/u-boot-mips

- tree-wide: introduce LDFLAGS_STANDALONE
- MIPS: fix long-standing issue with linking of standalone programs
- MIPS: MT76xx: add GPIO and WDT drivers
- MIPS: MT76xx: various fixes and updates to gardena-smart-gateway board
- MIPS: MT76xx: various fixes and updates to linkit-smart-7688 board

MIPS: fix linking of standalone programs

Use the global MIPS specific u-boot.lds for linking standalone programs
instead of the outdated ones in examples/standalone/. Also pass --gc-sections
in LDFLAGS_STANDALONE to optimize the size of standalone programs.
Finally remove the deprecated config.mk files in arch/mips/cpu/mips[32,64]/.

Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

Kbuild: standalone: do not ignore platform-specific OBJCOPYFLAGS

Currently the OBJCOPYFLAGS are cleared when assigning "-O srec"
or "-O binary" for standalone programs. All flags set by arch-specific
Makefiles are lost. This is bad if an arch demands arch-specific
flags for the objcopy step.

Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Kbuild: add LDFLAGS_STANDALONE

Introduce a new Makefile variable for passing LDFLAGS to standalone
programs. Currently the variable CONFIG_STANDALONE_LOAD_ADDR is
misued on some archs to pass a specific linker script.

Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Rick Chen <rick@andestech.com>

mips: mt76xx: linkit-smart-7688: Misc updates to dts/config/defconfig

These misc updates include the following changes:
- Change baudrate from 57600 to 115200
- Enable MIPS_BOOT_CMDLINE_LEGACY
- Enable FIT support
- Enable ethernet support
- Enable SPI support
- Enable GPIO support
- Change max image size from 0x40000 to 0x80000

A note about the baudrate change:

The original Mediatek U-Boot version used 57600 baud. Lets move to a
more common and faster speed of 115200 baud. And remove the "console="
property from the DT as its not needed.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

mips: mt76xx: linkit-smart-7688: Use ioremap_nocache to get address

Use the correct function to get the uncached address to access the SoC
registers.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

mips: mt76xx: gardena-smart-gateway: Misc updates to dts/config/defconfig

These misc updates include the following changes:
- Change baudrate from 57600 to 115200
- Enable MIPS_BOOT_CMDLINE_LEGACY
- Enable FIT support
- Enable ethernet support
- Enable SPI NOR and NAND support
- Change MTD_UBI_BEB_LIMIT to 22
- Enable MTD Support
- Enable GPIO support
- Enable watchdog support
- Enable bootcounter support
- Enable version variable
- Change max image size from 0x80000 to 0xa0000
- Change SYS_MALLOC_LEN to 16MiB (because of UBI/UBIFS)

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

mips: mt76xx: gardena-smart-gateway: Add board_late_init() to set LED def state

This is needed to set the LEDs automatically to a default state, as
configured in the dts.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

mips: mt76xx: gardena-smart-gateway: Add LEDs to dts

Add the available LEDs to the DTS file so that they can be used.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

mips: mt76xx: gardena-smart-gateway: Configure GPIOs (digital vs analog)

Configure digital vs analog GPIOs as needed on this board.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

mips: mt76xx: Enable watchdog support

This patch enables and starts the watchdog on the MT7620 platform.
Currently the WD timeout is configured to 60 seconds.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
[fixed build error due to missing function prototype arch_misc_init]
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

mips: mt76xx: Kconfig: Add ethernet and GPIO support

Imply DM_ETH and DM_GPIO for ARCH_MT7620, as this platform now supports
ethernet and GPIO as well.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

mips: mt76xx: Add watchdog DT node to mt7628a.dtsi

Add the watchdog DT node to the DTS file.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

mips: mt76xx: Add GPIO DT nodes to mt7628a.dtsi

Add the GPIO DT nodes to the DTS file.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

mips: mt76xx: Add ethernet DT node to mt7628a.dtsi

Add the ethernet DT node to the DTS file.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

mips: mt76xx: lowlevel_init.S: Add missing memory controller reset in DDR init

This fixes an issue which has been noticed on the Gardena board, with
the watchdog enabled, where the watdchdog reset (after a system hang)
did result in reporting of 2.9 GiB and a hang after this. With this
patch applied the memory controller is correctly reset and initialized
again even after a watchdog reset.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

gpio: Add MT7621 GPIO support

This patch adds GPIO support for the Mediatek MT7621 SoC, tested on
MT7688 (Gardena smart-gateway). The driver is loosly based on the
Linux kernel version.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
[fixed checkpatch.pl warnings: Prefer 'unsigned int' to bare use of 'unsigned']
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

wdt: Add MT7621 watchdog driver

This patch adds watchdog support for the Mediatek MT7621 SoC. The driver
is loosly based on the Linux kernel version.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
[fixed merge conflict in drivers/watchdog/Kconfig]
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

Merge branch '2018-11-16-master-imports'

- Initial bcm968580xref, am65x_evm_r5 support
- lpc32xx, omap3_logic/am3517_evm updates
- pinctrl command
- fs_loader available for SPL

sunxi: Update MAINTAINERS file for recent boards

Add entries for the pine64-lts and pinebook configs.

Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

fdt_region: Ensure that depth never goes below -1

A specially crafted FIT image makes it possible to overflow the stack
with controlled values when using the verified boot feature. Depending
on the memory layout, this could be used to overwrite configuration
variables on the heap and setting them to 0, e.g. disable signature
verification, thus bypassing it.

This change fixes a bug in fdt_find_regions where the fdt structure is
parsed. A lower value than -1 of depth can lead to a buffer underflow
write on the stack.

Signed-off-by: Konrad Beckmann <konrad.beckmann@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

image-sig: Ensure that hashed-nodes is null-terminated

A specially crafted FIT image leads to memory corruption in the stack
when using the verified boot feature. The function fit_config_check_sig
has a logic error that makes it possible to write past the end of the
stack allocated array node_inc. This could potentially be used to bypass
the signature check when using verified boot.

This change ensures that the number of strings is correct when counted.

Signed-off-by: Konrad Beckmann <konrad.beckmann@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Ability to modify distro boot filename

Add in the ability to modify the distro boot filename. Whilst not
immediately useful in normal usage, it allows an alternative
configuration to be provided when other u-boot functionality is used, such
as bootcount limit, to fallback to an alternative boot configuration. In
this case we can follow the same boot path as for normal boot, just
using an alternatively named configuration file.

For example, by providing the following `altbootcmd` when bootcount is in
use:

altbootcmd=setenv boot_extlinx_conf extlinux-rollback.conf; \
run distro_bootcmd

Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

misc: fs_loader: Fix compiler warning

Fix compiler warning

drivers/misc/fs_loader.c:193:9: warning: format ‘%d’ expects
argument of type ‘int’, but argument 5 has type ‘size_t
{aka long unsigned int}’ [-Wformat=]

Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

misc: fs_loader: Use device_get_global_by_ofnode to get to node

Instead of two staged ofnode_to_offset followed by
device_get_global_by_of_offset approach, direcly use the
device_get_global_by_ofnode to fetch the device.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

fs: Makefile: Add fs.c under SPL for fs_loader

Add fs.c under SPL as well as it is needed for fs_loader

Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Add as obj-$(CONFIG_FS_LOADER) for non-SPL_FRAMEWORK builds]
Signed-off-by: Tom Rini <trini@konsulko.com>

serial: ns16550: add setconfig support

Add possibility to update the serial parity used.

Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com>

dm: serial: fix comment on dm_serial_ops setconfig

The comment on this function prototype describes nonexistent
parameters. It seems to be copied from 'setparity'.

Update it to match its the parameter list.

Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

board: ti: am65x: Update README to add R5 build support

Update the README file to add r5 build support and system
firmware support.

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

configs: am65x_evm_r5: Add initial support

Add initial defconfig support for AM65x
that runs on R5.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>

armv7r: dts: am654: Add initial support

Add R5 specific dts for am654-evm.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Schuyler Patton <spatton@ti.com>
Signed-off-by: James Doublesin <doublesin@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm: dts: k3: Sync dts from Linux

Sync the k3-am654 specific dts files from Linux next with tag
20181019. This changes are in queue for Linux v4.20-rc1

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

board: ti: am654: r5: Add initial support for am654

Add initial support for AM654 based EVM running on R5.

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

armv7R: K3: am654: Add support for triggering ddr init from SPL

In SPL, DDR should be made available by the end of board_init_f()
so that apis in board_init_r() can use ddr. Adding support
for triggering DDR initialization from board_init_f().

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

armv7R: K3: am654: Add support to start ATF from R5 SPL

Considering the boot time requirements, Cortex-A core
should be able to start immediately after SPL on R5.
Add support for the same.

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

armv7R: K3: am654: Add support for generating build targets

Update Makefiles to generate:
- tiboot3.bin: Image format that can be processed by ROM.

Below is the tiboot3.bin image format that is required by ROM:

 _______________________
|  X509 |
|     Certificate |
| ____________________ |
| |       | |
| | u-boot-spl.bin    | |
| |       | |
| |___________________| |
|_______________________|

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

armv7R: K3: am654: Enable MPU regions

Enable MPU regions for AM654 evm:
- Region0: 0x00000000 - 0xFFFFFFFF: Device memory, not executable
- Region1: 0x41c00000 - 0x42400000: Normal, executable, WB, Write alloc
- Region2: 0x80000000 - 0xFFFFFFFF: Normal, executable, WB, Write alloc
- region3-15: Disabled

With this dcache can be enabled either in SPL or U-Boot.

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

ram: Introduce K3 AM654 DDR Sub System driver

K3 based AM654 devices has DDR memory subsystem that comprises
Synopys DDR controller, Synopsis DDR phy and wrapper logic to
intergrate these blocks into the device. This DDR subsystem
provides an interface to external SDRAM devices. Adding support
for the initialization of the external SDRAM devices by
configuring the DDRSS registers and using the buitin PHY
routines.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Schuyler Patton <spatton@ti.com>
Signed-off-by: James Doublesin <doublesin@ti.com>

i2c: stm32f7: change setup struct to const

Change static array to const when it is useful to save memory
(move stm32f7_setup=0x18 from .data to .rodata section)

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

i2c: stm32f7: cosmetic: clean the driver

Solve alignments issues in the driver to avoid
checkpatch error.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

ARM: am3517_evm: Remove SPL_OF_CONTROL and OF_PLATDATA

After the recomendation, some testing shows like these are unnecessary.

Suggested-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: omap3_logic: Remove SPL_OF_CONTROL and OF_PLATDATA

After the recomendation, some testing shows like these are unnecessary.

Suggested-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Adam Ford <aford173@gmail.com>

arm: Make arch specific memcpy thumb-safe.

The current arch implementation of memcpy cannot be called
from thumb code, because it does not use bx instructions on return.
This patch addresses that. Note, that this patch does not touch
the hot loop of memcpy, so performance is not affected.

Tested on MXS (arm926ejs) with and without thumb-mode enabled.

Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>

test/py: test pinmux command

Add pinmux test which test the following commands:
  - pinmux list
  - pinmux dev
  - pinmux status

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Mark some tests as sandbox-centric]
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

pinctrl: sandbox: Add get_pin_muxing ops support

Add get_pin_mux ops support to display the pin muxing
description of the sandbox_pins[]

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

gpio: stm32f7: Add ops get_function

This patch adds gpio get_function ops support.
This function reports the state of a gpio.

Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>

pinctrl: stm32: Add get_pin_muxing() ops

Add get_pin_muxing() ops to obtain the pin muxing description
a given pin index.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

pinctrl: stm32: Add get_pin_name() ops

Add get_pin_name ops to obtain a pin name given a
pin index of a specified pin-controller.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

pinctrl: stm32: Add get_pins_count() ops

Add get_pins_count ops to obtain the number of pins
owns by a pin-controller.
On STM32 SoCs bindings, each pin-controller owns
several gpio banks. Each GPIO bank can own up to 16 pins.

To obtain the total pins count, walk through each sub-nodes
(ie GPIO banks) and sum each GPIO banks pins number. For that
in probe() we build a list with each GPIO device reference found.
This list will also be used with future get_pin_muxing and get_pin_name
ops to speed up and optimize walk through all GPIO banks.

As this code is common to all STM32 SoCs, this code is put
under SPL_BUILD compilation flag to avoid to increase SPL code size
for STM32F7 which is limited to 32Ko.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: pinmux: Add pinmux command

pinmux command allows to :
 - list all pin-controllers available on platforms
 - select a pin-controller
 - display the muxing of all pins of the current pin-controller
   or all pin-controllers depending of given options

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
cmd: pinmux: Fix pinmux command

if "pinmux status" command is used without having
set dev using "pinmux dev", print pinmux usage
Reviewed-by: Simon Glass <sjg@chromium.org>

dm: uclass: Add uclass_foreach_dev_probe

Add uclass_foreach_dev_probe() which iterates through
devices of a given uclass. Devices are probed if necessary
and are ready to use.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

dm: uclass: Add uclass_next_device_err() to return a valid device

Similarly to uclass_first_device_err(), add uclass_next_device_err()
which returns an error if there are no next devices in that uclass.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

dm: pinctrl: Add pinctrl_get_pin_name and pinctrl_get_pins_count

Add pinctrl_get_pin_name() and pinctrl_get_pins_count() methods
to obtain pin's name and pin's muxing given a pin reference.

This will be used by the new pinmux command.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

dm: pinctrl: Add get_pin_muxing() ops

Add get_pin_muxing() which allows to display the muxing
of a given pin belonging to a pin-controller.

Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

w1-eeprom: Add support for Maxim DS2502 add only memory

Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>

ARM: omap3_logic: Make CONFIG_SYS_TEXT_BASE match README.omap3

README.omap3 has two options.  For option 1, CONFIG_SYS_TEXT_BASE
is set to 0x80100000.  Option 2 lists 0x80008000.  The existing
value is neither of these, so this patch makes it equivalent to
Option 1.

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

ARM: am3517_evm: Build for Thumb

In an effort to free up more resources in SPL and U-Boot, building
for Thumb shrinks the code side.

Before:

  text    data     bss     dec     hex filename
  685588  25808  275724  987120   f0ff0 u-boot

  text    data     bss     dec     hex filename
  55324     417   67460  123201   1e141 spl/u-boot-spl

After:

   text    data     bss     dec     hex filename
 515502   25808  275708  817018   c777a u-boot

   text    data     bss     dec     hex filename
  42910     417   67460  110787   1b0c3 spl/u-boot-spl

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

configs: am3517_evm: Use default OMAP3 memory settings

The AM3517 is mostly am omap3, so this partch removes the custom
memory configurations and just uses the default common entries
for omap3 and armv7.

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

ARM: DTS: Resync am3517-evm.dts with Linux 4.19

Some minor changes have been made to the AM3517-evm and the underlying
am3517.dtsi files.  This patch re-sync's the DTS and DTSI files with
Linux.

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

mtd: nand: lpc32xx slc: disable DMA support in SPL builds

Testing and analysis shows that at the moment LPC32xx NAND SLC driver
can not get PL080 DMA backbone support in SPL build, because SPL NAND
loaders operate with subpage (ECC step to be precisely) reads, and
this is not supported in the NAND SLC + DMA + hardware ECC calculation
bundle.

The change removes a cautious build time warning and explicitly
disables DMA flavour of the driver for SPL builds, to reduce the
amound of #ifdef sections the code blocks are minimally reorganized.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>

mtd: nand: lpc32xx mlc: predefine number of NAND chips to support

Build option CONFIG_SYS_MAX_NAND_CHIPS is used by NXP LPC32xx NAND MLC
driver only, as a preparation for potential removal or replacement of
the option the change predefines CONFIG_SYS_MAX_NAND_CHIPS to 1, same
value is used by the single user Work Microwave Work 92105 board, thus
it will be safe now to remove the option as a board specific one.

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

gpio: pca953x: Clear the polarity invert register at init

The pca953x_gpio driver uses default value of polarity inversion
register. For some devices like PCA9557 and MAX7310, their polarity
inversion register default value is 0xf0. So for high 4 ports, when
reading their values, the values are inverted as the actual level.

This patch clears the polarity inversion register to 0 at init, so
that the port read and write values are aligned.

Signed-off-by: Ye Li <ye.li@nxp.com>
Acked-by: Fugang Duan <fugang.duan@nxp.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Anatolij Gustschin <agust@denx.de>

clk: Allow clock defaults to be set also during re-reloc state

The earlier commit f4fcba5c5ba ("clk: implement clk_set_defaults()")
which introduced the functionality for setting clock defaults such as
rates and parents will skip the processing when executing in a re-reloc
state. This for example can prevent the assigning of clock parents
when running in SPL code. Go ahead and remove this limitation.

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

bcm968580xref: add initial support

This add the initial support of the broadcom reference
board bcm968580xref with a bcm6858 SoC.

This board has 512 MB of ram, 256 MB of flash (nand),
2 usb port, 1 uart, 4 ethernet ports (LAN), 1 ethernet port (WAN).

Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>

bcm6858: add initial support

This add the initial support of the broadcom bcm6858 SoC family,
only the cpu, dram and uart are supported.

Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>

serial: bcm6858: add serial support

This driver add the support of serial on bcm6858.
It's based on serial for bcm6345.

Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>

cmd/bdinfo: correct output of numerical values

Display all digits on 64bit systems. Currently we print only the lower
32 bits. Examples of values that can exceed 32 bits are the size and start of
memory banks.

For fdt_blob use the same output method as for other values. This avoids
misalignment.

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

arm: at91: wdt: Convert watchdog driver to dm/dt

Convert the Watchdog driver for AT91SAM9x processors to support
the driver model and device tree. Changes "CONFIG_AT91SAM9_WATCHDOG"
to new "CONFIG_WDT_AT91" Kconfig option.

Signed-off-by: Prasanthi Chellakumar <prasanthi.chellakumar@microchip.com>

ARMv8: SError exception handling in PSCI exception vectors

Allow platform vendors to handle SError interrupt exceptions from
ARMv8 PSCI exception vectors by overriding this weak function
'plat_error_handler'.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>

ARMv8: Add EL3 exception handling for ARMv8's Kconfig

Kconfig option to allow all External Abort and SError exception
taken to EL3.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>

ARMv8: Enable all asynchronous abort exceptions taken to EL3

Allow EL3 to handle all the External Abort and SError interrupt
exception occur in all exception levels.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>

configs: Enable THUMB2 on various ARM boards

The clearfog, corvus, wb45n and picosam9g45 configs are close to
exceeding their size limits, so enable THUMB2 builds on them to reclaim
space.

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

Merge tag 'pull-14nov18' of git://git.denx.de/u-boot-dm

- virtio implementation and supporting patches
- DM_FLAG_PRE_RELOC fixes
- regmap improvements
- minor buildman and sandbox things

travis: Ensure we use pytest 2.8.7

The latest version of pytest (4.0.0) makes some of the code we have in
test/py/conftest.py a fatal error that needs to be migrated.
Unfortunately this in turn requires changes that don't exist in older
versions of pytest such as 2.8.7 that ships with Ubuntu 16.04.  Force
travis to use this older version of pytest.

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

Merge branch 'master' of git://git.denx.de/u-boot-sunxi

Revert "imx8qxp_mek: Disable CONFIG_DISPLAY_CPUINFO"

This reverts commit c5bbfaf05dc8592b479a44df6abaadbab54fec2b.

Disabling CONFIG_DISPLAY_CPUINFO was a temporary solution to get
the v2018.11 release out. Now the merge window opens, revert it.

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

cpu: sandbox: Add "u-boot, dm-pre-reloc" for all cpu nodes

To support CONFIG_DISPLAY_CPUINFO, add "u-boot,dm-pre-reloc" for
all cpu nodes in Sandbox test.dts.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>

cpu: Add DM_FLAG_PRE_RELOC flag to various cpu drivers

It turns out commit c0434407b595 broke some boards which have DM CPU
driver with CONFIG_DISPLAY_CPUINFO option on. These boards just fail
to boot when print_cpuinfo() is called during boot.

Fixes: c0434407b595 ("board_f: Use static print_cpuinfo if CONFIG_CPU is active")
Reported-by: Stefan Roese <sr@denx.de>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>

dm: doc: Update description of pre-relocation support

Add some description about pre-relocation driver binding, including
usage of DM_FLAG_PRE_RELOC flag and caveats.

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

watchdog: Remove DM_FLAG_PRE_RELOC flag in various drivers

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree

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

video: simplefb: Remove DM_FLAG_PRE_RELOC flag

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree

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

sysreset: Remove DM_FLAG_PRE_RELOC flag in various drivers

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree

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

serial: Remove DM_FLAG_PRE_RELOC flag in various drivers

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree

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

timer: Remove DM_FLAG_PRE_RELOC flag in various drivers

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree

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

ram: bmips: Remove DM_FLAG_PRE_RELOC flag

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree

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

pinctrl: Remove DM_FLAG_PRE_RELOC flag in various drivers

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree

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

mmc: omap: Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree

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

i2c: omap24xx: Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree

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

gpio: Remove DM_FLAG_PRE_RELOC flag in various drivers

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree

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

clk: Remove DM_FLAG_PRE_RELOC flag in various drivers

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree

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

arm: stm32mp: Remove DM_FLAG_PRE_RELOC flag

When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be
bound before relocation. However due to a bug in the DM core,
the flag only takes effect when devices are statically declared
via U_BOOT_DEVICE(). This bug has been fixed recently by commit
"dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in
lists_bind_fdt()", but with the fix, it has a side effect that
all existing drivers that declared DM_FLAG_PRE_RELOC flag will
be bound before relocation now. This may expose potential boot
failure on some boards due to insufficient memory during the
pre-relocation stage.

To mitigate this potential impact, the following changes are
implemented:

- Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver
  only supports configuration from device tree (OF_CONTROL)
- Keep DM_FLAG_PRE_RELOC flag in the driver only if the device
  is statically declared via U_BOOT_DEVICE()
- Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for
  drivers that support both statically declared devices and
  configuration from device tree

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

serial: ns16550: fix debug uart putc called before init

If _debug_uart_putc() is called before _debug_uart_init(), the
ns16550 debug uart driver hangs in a tight loop waiting for the
tx FIFO to get empty.

As this can happen via a printf sneaking in before the port calls
debug_uart_init(), let's rather ignore characters before the debug
uart is initialized.

This is done by reading the baudrate divisor and aborting if is zero.

Tested on socfpga_cyclone5_socrates.

Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

uclass: Use uclass_foreach_dev() macro instead of open coding

Use the uclass_foreach_dev() macro instead of the open coded version.

Signed-off-by: Liviu Dudau <liviu.dudau@foss.arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

doc: Document virtio support

Add REAME.virtio to describe the information about U-Boot support for
VirtIO devices, including supported boards, build instructions, driver
details etc.

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

test: dm: virtio: Add test cases for virtio uclass

Now that we have a sandbox virtio transport driver, add some test
cases to test virtio uclass driver.

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