There are already Kconfig options for SPI drivers, but we
have not moved them from config.h to defconfig files. This
commit does this in a batch.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>

This commit provides definition and declaration of GPT verification
functions - namely gpt_verify_headers() and gpt_verify_partitions().
The former is used to only check CRC32 of GPT's header and PTEs.
The latter examines each partition entry and compare attributes such as:
name, start offset and size with ones provided at '$partitions' env
variable.
Signed-off-by: NLukasz Majewski <l.majewski@majess.pl>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NPrzemyslaw Marczak <p.marczak@samsung.com>

Add initial sun8i H3 support, only uart + mmc are supported for now.
Signed-off-by: NJens Kuske <jenskuske@gmail.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

The DFU protocol implementation in U-Boot is much faster than the
FEL protocol implementation in the boot ROM on Allwinner devices.
Using DFU instead of FEL improves the USB transfer speed from
500-900 KB/s to 3.2-3.7 MB/s. This is particularly useful for
reducing the time needed for booting systems with large initrd
images.

FEL is still useful for loading the U-Boot bootloader and a boot
script, which may then activate DFU in the following way:

   setenv dfu_alt_info ${dfu_alt_info_ram}
   dfu 0 ram 0
   bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

The rest of the files can be transferred to the device using the
"dfu-util" tool.
Signed-off-by: NSiarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Add support for storing the environment in CFI NOR flash on Juno and FVP
models.

I also removed some config values that are not used by CFI flash parts.

Juno has 1 flash part with 259 sectors.  The first 255 sectors are
0x40000 (256kb) and are followed by 4 sectors of 0x10000 (64KB).

FVP models simulate a 64MB NOR flash part at base address 0x0FFC0000.
This part has 256 x 256kb sectors.  We use the last sector to store the
environment.

To save the NOR flash to a file, the following parameters should be
passed to the model:

    -C bp.flashloader1.fname=${FILENAME}
    -C bp.flashloader1.fnameWrite=${FILENAME}

Foundation models don't simulate the NOR flash, but having NOR support
in the u-boot binary does not harm:  attempting to write to the NOR will
fail gracefully.
Signed-off-by: NRyan Harkin <ryan.harkin@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

This patch allows vexpress64 targets to be compiled when
CONFIG_SYS_FLASH_CFI is enabled.

I considered using #warning instead of #error, but this just clutters up
the build output and hides real warnings.

Without this patch, you see errors during compilation like this:

include/configs/vexpress_aemv8a.h:42:2: error: #error "Unknown board
variant"
 #error "Unknown board variant"
include/configs/vexpress_aemv8a.h:115:2: error: #error "Unknown board
variant"
 #error "Unknown board variant"
include/configs/vexpress_aemv8a.h:280:2: error: #error "Unknown board
variant"
 #error "Unknown board variant"
make[1]: *** [tools/envcrc.o] Error 1
make: *** [tools] Error 2
In file included from include/config.h:5:0,
                 from tools/envcrc.c:19:
Signed-off-by: NRyan Harkin <ryan.harkin@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

This patch makes the 2nd DRAM bank available on Juno only and not on
other vexpress64 targets, eg. the FVP models.

The commit below added a 2nd bank of NOR flash for Juno, but also for
all vexpress64 targets:

    commit 2d0cee1c
    Author: Liviu Dudau <Liviu.Dudau@foss.arm.com>
    Date:   Mon Oct 19 11:08:31 2015 +0100

    vexpress64: Juno: Declare all 8GB of RAM and make them visible to the kernel.

    Juno comes with 8GB RAM, but U-Boot only passes 2GB to the kernel.
    Declare a secondary memory bank and set the sizes correctly.
Signed-off-by: NLiviu Dudau <Liviu.Dudau@foss.arm.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NRyan Harkin <ryan.harkin@linaro.org>
Tested-by: NRyan Harkin <ryan.harkin@linaro.org>

Unfortunately, I only fully tested on Juno R0, R1 and the FVP Foundation
model.  Whilst FVP Base AEMV8 models run U-Boot OK, they fail to boot
the kernel.
Signed-off-by: NRyan Harkin <ryan.harkin@linaro.org>
Acked-by: NLiviu Dudau <liviu.dudau@foss.arm.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

Add bus argument to eeprom_init(), so that it can select
the I2C bus number on which the eeprom resides. Any negative
value of the $bus argument will preserve the old behavior.
This is in place so that old code does not randomly break.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: NHeiko Schocher <hs@denx.de>
[trini: Wrap i2c_set_bus_num() call with CONFIG_SYS_I2C test]
Signed-off-by: NTom Rini <trini@konsulko.com>

Remove this function as it's no longer used.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: NHeiko Schocher <hs@denx.de>

This option only complicates the code unnecessarily, just use
CONFIG_SYS_DEF_EEPROM_ADDR as the default address if there are
only five arguments to eeprom {read/write} if this is defined.
If CONFIG_SYS_DEF_EEPROM_ADDR is not defined, we mandate all
six arguments.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: NHeiko Schocher <hs@denx.de>

The NOR flash on Keystone 2 evms has a u-boot-spl partition size of
0x80000.

Currently burn_uboot_spi will erase 0x100000 from the spi NOR which will
cause a partial erase of the misc partition.

Fix this by correcting the erase size.
Signed-off-by: NFranklin S Cooper Jr <fcooper@ti.com>

Change to ns16550 uart for 10m50 devboard based on a new
Altera release.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>
Reviewed-by: NTom Rini <trini@konsulko.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Move CONFIG_SYS_NS16550 to Kconfig, and run moveconfig.py.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>

Zap CONFIG_NS16550_SERIAL, as the unification of ns16550 drivers
is completed.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Unify serial_omap, and use the generic binding.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>
Reviewed-by: NTom Rini <trini@konsulko.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Unify serial_tegra, and use the generic binding.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>
Reviewed-by: NTom Rini <trini@konsulko.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Unify serial_dw, and use the generic binding.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>
Reviewed-by: NTom Rini <trini@konsulko.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Unify serial_keystone, and use the generic binding.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>
Reviewed-by: NTom Rini <trini@konsulko.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Enable the USB keyboard on sandbox, now that we have a suitable emulation
driver.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add a simple USB keyboard driver for sandbox. It provides a function to
'load' it with input data, which it will then stream through to the normal
U-Boot input subsystem. When the input data is exhausted, the keyboard stops
providing data.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Allow USB device emulation to support interrupt URBs so that we can use USB
keyboards with sandbox.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This reverts commit bb52b367.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Each USB device has an emulator. Currently this can only be found by
supplying the 'pipe' value, which contains the device number. Add a way
to find it directly from the emulated device.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Add iteration macros which support unbinding a device within the loop.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Allow the 'usb tree' command to be used from test code, so that we can
verify that it works correctly.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Allow console recording so that tests can use it. Also allow the console
output to be suppressed, to reduce test output 'noise'.
Signed-off-by: NSimon Glass <sjg@chromium.org>

It is useful to be able to record console output and provide console input
via a buffer. This provides sandbox with the ability to run a command and
check its output. If the console is set to silent then no visible output
is generated.

This also provides a means to fix the problem where tests produce unwanted
output, such as errors or warnings. This can be confusing. We can instead
set the console to silent and record this output. It can be checked later
in the test if required.

It is possible that this may prove useful for non-test situations. For
example the console output may be suppressed for normal operations, but
recorded and stored for access by the OS. That feature is not implemented
at present.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This will be used to support console recording. It provides for a circular
buffer which can be written at the head and read from the tail. It supports
avoiding data copying by providing raw access to the data.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The console includes a global variable and several functions that are only
used by a small subset of U-Boot files. Before adding more functions, move
the definitions into their own header file.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Convert to use driver model keyboard on QEMU.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Convert to use driver model keyboard on Intel Crown Bay.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

When sending LED update command to an i8042 compatible keyboard,
bit1 is 'Num Lock' and bit2 is 'Caps Lock' in the data byte. But
input library defines bit1 as 'Caps Lock' and bit2 as 'Num Lock'.
This causes a wrong LED to be set on an i8042 compatible keyboard.
Change the LED state bits to be i8042 compatible, and change the
keyboard flags as well.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

This has duplicated scan code tables and logic. We can use the input
library to implement most of the features here.

This needs testing. The only supported board appears to be TQM5200.
Unfortunately no maintainer is listed for this board.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Adjust this driver to support driver model. The only users are x86 boards
so this should be safe.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>

This option is mentioned but does not do anything. Drop it.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Some boards have an i8042 device. Enable the driver for all x86 boards, and
add a device tree node for those which may have this keyboard.

Also adjust the configuration so that i8042 is always separate from the VGA,
and rename the stdin driver accordingly. With this commit the keyboard will
not work, but it is fixed in the next commit.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Add a function which returns a new keyboard LED value when the LEDs need
updating.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Add support for the German keymap, taken from i8042.c. This can be selected
when the input library it initialised.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Add a sandbox timer which get time from host os and a basic
test.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Generally the input library handles processing of a list of scanned keys.
Repeated keys need to be generated based on a timer in this case, since all
that is provided is a list of keys current depressed.

Keyboards which do their own scanning will resend codes when they want to
inject a repeating key. Provide a function which tells the input library to
accept repeating keys and not to try to second-guess the caller.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>