OMAP3: zoom1: Configure GPMC for Ethernet

zoom1 uses LAN9211 configured over GPMC Chip Select 1.

Signed-off-by: Nishanth Menon <nm@ti.com>

omap3: zoom1: enable CONFIG_SYS_GENERIC_BOARD

CONFIG_SYS_GENERIC_BOARD should now be enabled for generic
functionality Further information in doc/README.generic-board

Signed-off-by: Nishanth Menon <nm@ti.com>

keystone2: net: add keystone ethernet driver

Ethernet driver configures the CPSW, SGMI and Phy and uses
the the Navigator APIs. The driver supports 4 Ethernet ports and
can work with only one port at a time.

Port configurations are defined in board.c.

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: WingMan Kwok <w-kwok2@ti.com>

keystone2: add keystone multicore navigator driver

Multicore navigator consists of Network Coprocessor (NetCP) and
Queue Manager sub system. More details on the hardware can
be obtained from the following links:-

Network Coprocessor: http://www.ti.com/lit/pdf/sprugz6
Multicore Navigator: http://www.ti.com/lit/pdf/sprugr9

Multicore navigator driver implements APIs to configure
the Queue Manager and NetCP Pkt DMA.

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
Acked-by: Tom Rini <trini@ti.com>

k2hk-evm: add configuration for spi1 and spi2 support

currently only spi0 is enabled on k2hk evm. This
configuration update is needed to enable spi1 and spi2.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Tom Rini <trini@ti.com>

spi: davinci: add support for multiple bus and chip select

Currently davinci spi driver supports only bus 0 cs 0.
This patch allows driver to support bus 1 and bus 2 with
configurable number of chip selects. Also defaults are
selected in a way to avoid regression on other platforms
that uses davinci spi driver and has only one spi bus.

Signed-off-by: Rex Chang <rchang@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>

k2hk: add support for k2hk SOC and EVM

k2hk EVM is based on Texas Instruments Keystone2 Hawking/Kepler
SoC. Keystone2 SoC has ARM v7 Cortex-A15 MPCore processor. Please
refer the ti/k2hk_evm/README for details on the board, build and other
information.

This patch add support for keystone architecture and k2hk evm.

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
Signed-off-by: Sandeep Nair <sandeep_n@ti.com>

i2c, davinci: convert driver to new mutlibus/mutliadapter framework

    - add davinci driver to new multibus/multiadpater support
    - adapted all config files, which uses this driver

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Heiko Schocher <hs@denx.de>

i2c, davinci: move i2c_defs.h to the drivers/i2c directory

This patch moves the davinci i2c_defs.h file to drivers.i2c directory.
It will allow to reuse the davinci_i2c driver for TI Keystone2 SOCs.

Not used "git mv" command to move the file because small part of
it with definitions specific for Davinci SOCs has to remain in the
arch/arm/include/asm/arch-davinci.

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Tom Rini <trini@ti.com>

NAND: DaVinci: allow forced disable of subpage writes

This patch introduces a configurable mechanism to disable
subpage writes in the DaVinci NAND driver.

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Tom Rini <trini@ti.com>

arm: add support for arch timer

This patch add basic support for the architecture timer found on recent
ARMv7 based SoCs.

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>

tools: mkimage: add support for gpimage format

This patch add support for gpimage format as a preparatory
patch for porting u-boot for keystone2 devices and is
based on omapimage format. It re-uses gph header to store the
size and loadaddr as done in omapimage.c

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Tom Rini <trini@ti.com>

fdt: call ft_board_setup_ex() at the end of image_setup_libfdt()

The keystone2 SOC requires to fix all 32 bit aliased addresses
to their 36 physical format. This has to happen after all fdt
nodes are added or modified.

Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Tom Rini <trini@ti.com>

TI:omap3: Convert omap3_beagle to ti_omap3_common.h

Convert to using the common config files.  This requires a little more
flexibility in the common files than we had been using before.

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

TI:armv7: Switch to CONFIG_SYS_BOARD_GENERIC

Tested on AM335x GP EVM, AM335x EVM SK, Beaglebone White, Beaglebone
Black, AM437xx GP EVM, OMAP5 uEVM, OMAP4 Pandaboard

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

dra7xx_evm: Add QSPI_4 support, qspiboot build target

We previously only supported QSPI_1 (single) support.  Add QSPI_4 (quad)
read support as well.  This means we can be given one of two boot device
values, but don't care which it is, so perform a fixup on the QSPI_4
value.  We add a qspiboot build target to better show how you would use
QSPI as a boot device in deployment.  When we boot from QSPI, we can
check the environment for 'boot_os' to control Falcon Mode.

Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>

SPL:SPI: Add Falcon Mode support

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

am335x_evm: Drop SPI SPL support from the default build

This is only useful with the _spiboot build target anyhow, so only
include it then.  Drop CONFIG_SPL_OS_BOOT support then as the flash is
small and didn't include a spot for the device tree already.

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

spi: ti_qspi: Add delay for successful bulk erase.

Bulk erase is not happening properly on dra7 due to erase timing constraints,
add a delay so that erase timing constraints are properly met.

Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Tested-by: Yebio Mesfin <ymesfin@ti.com>

TI:armv7: Change Falcon Mode DT load address

In general, we want to load the DT at base+128MB, so that we ahve
sufficient room for the kernel and a larger device tree.  In the case of
OMAP3, use 64MB instead as we have a number of boards with 128MB DDR.

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

TI:omap5: Move CONFIG_ENV_SIZE to board config files

The size of the environment depends on the backing store, move this to
the board config files.

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

am43xx_evm: Update the ramdisk args, we pass things in just fine via DT

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

am335x_evm: Update the ramdisk args, we pass things in just fine via DT

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

TI: Add, use a DEFAULT_LINUX_BOOT_ENV environment string

To deal with a reoccurring problem properly we need to specify addresses
for the Linux kernel, Flatted Device Tree and ramdisk that obey the
constraints within the kernel's Documentation/arm/Booting file but also
make sure that we relocate things within a valid address range.

It is possible with these addresses to also set fdt_high and initrd_high
to the value of 0xffffffff.  We don't do this by default to allow for
the most likely success of people using custom addresses however.

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

spl_mmc/CONFIG_SPL_OS_BOOT: Allow environment to determine what to boot

We add two new environment variables, falcon_args_file and
falcon_image_file, which when set will override the compiled in default
values for falcon mode.

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

a3m071: Make spl_start_uboot test like getenv_yesno does

This change makes the behaviour slightly more rebust and will match
other implementations which can use getenv_yesno directly.

Acked-by: Stefan Roese <sr@denx.de>
Signed-off-by: Tom Rini <trini@ti.com>

README.falcon: Document environment variables for falcon mode

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

README: Add CONFIG_SPL_OS_BOOT to README

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

am335x_evm: Make SPL_OS also check the boot_os variable for falcon mode

We use the same variable as a3m071 in the environment to determine if we
should boot into Linux or U-Boot.  This is useful on boards like
Beaglebone Black or AM335x GP EVM where we have persistent storage for
the environment.

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

mtd: Build nand_util.o for CONFIG_ENV_IS_IN_NAND in SPL

Acked-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Tom Rini <trini@ti.com>

mtd: Add a CONFIG_SPL_MTD_SUPPORT for a more full NAND subsystem in SPL

This mainly converts the am335x_spl_bch driver to the "normal" format
which means a slight change to nand_info within the driver.

Acked-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Tom Rini <trini@ti.com>

env_mmc.c: Remove NULL check on tmp_env1/2

With 452a272 we moved to allocating these variables on the stack.  So
they will never now be NULL so remove these checks.

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

env_mmc.c: Allow environment to be used within SPL

Inside of SPL we only concern ourself with one MMC device, so instead of
being able to use CONFIG_SYS_MMC_ENV_DEV we need to use 0 in SPL.
Switch the code to use a 'dev' variable to facilitate this.

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

fw_env.c: Switch get_config to use '%ms' in sscanf

We currently limit ourself to 16 characters for the device name to read
the environment from.  This is insufficient for /dev/mmcblk0boot1 to
work for example.  Switch to '%ms' which gives us a dynamically
allocated buffer instead.  We're short lived enough to not bother
free()ing the buffer.

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

OMAP3: beagle-xm: generate fake USB ethernet MAC address from dieid

Similar to OMAP5uEVM, PandaBoard, BeagleBoard-XM has a USB based
ethernet without MAC address embedded. So fake a MAC address following
the similar strategy used on OMAP5 and PandaBoard family.

Signed-off-by: Nishanth Menon <nm@ti.com>

omap3/sys_info: provide interface to read die id

introduce get_die_id() function which allows generation of
information such as fake MAC address from the processor ID code.

Signed-off-by: Nishanth Menon <nm@ti.com>

OMAP: common: consolidate fake USB ethernet MAC address creation

TI platforms such as OMAP5uevm, PandaBoard, use equivalent
logic to generate fake USB MAC address from device unique DIE ID.

Consolidate this to a generic location such that other TI platforms such
as BeagleBoard-XM can also use the same.

NOTE: at this point in time, I dont yet see a need for a generic dummy
ethernet MAC address creation function, but if there is a need in the
future, this can be further abstracted out.

Signed-off-by: Nishanth Menon <nm@ti.com>

ARM: OMAP: replace custom sr32() by standard I/O accessors

Replace the custom bit manipulation function sr32() by standard I/O
accessors.  A major motivation for this cleanup was the fact, that a
number of calls of that function resulted in 32 bit wide shift
operations on u32 data, which according to the C-ISO/IEC-9899-Standard
provokes undefined behaviour:

6.5.7 Bitwise shift operators
...
        If the value of the right operand is negative or is greater
        than or equal to the width of the promoted left operand, the
        behavior is undefined.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>

ARM: OMAP: hide custom bit manipulation function sr32()

The only remaining user of the custom bit manipulation function sr32()
is arch/arm/cpu/armv7/omap3/clock.c, so  make it a static function in
that file to prepare complete removal.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>

ARM: OMAP: remove sr32() from OMAP board code

Replace the custom sr32() bit manipulation function in
arch/arm/cpu/armv7/omap3/board.c and board/ti/panda/panda.c
by standard I/O accessors.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>

board:tricorder: fixup SPL OOB layout

Commit d016dc42cedbf6102e100fa9ecb58462edfb14f8 changed the layout of BCH8 SW
on omap3 boards. We need to adopt the ecc layout for the nand_spl_simle
driver to avoid wrong ecc errors.

Signed-off-by: Andreas Bießmann <andreas.biessmann@corscience.de>
Cc: Thomas Weber <thomas.weber@corscience.de>
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>

board:tricorder: enable omap_gpio clocks

Signed-off-by: Andreas Bießmann <andreas.biessmann@corscience.de>
Cc: Thomas Weber <thomas.weber@corscience.de>
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>

board:tricorder: always work with valid eeprom data

Commit 890880583d84607e36b52a785a96b167728bbf73 introduced EEPROM parsing and
board detection but faild to return a valid tricorder_eeprom struct for backup
case.  When pressing S200 while reading EEPROM we ignore the value. We
returned falsely a tricorder_eeprom struct with uninitialized data which is
just garbage.
Initialize it by zeroing the whole structure.

Signed-off-by: Andreas Bießmann <andreas.biessmann@corscience.de>
Cc: Thomas Weber <thomas.weber@corscience.de>
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>

arm:board:trats2:FIX: Clear INFORM4 and INFORM5 registers at correct boot

During switch to device tree, commit 1ecab0f has removed this code.

INFORM4 and INFORM5 registers are used by TRATS2 first stage bootloader for
providing recovery. For normal operation, those two must be cleared out.

This error emerges when one force reset from u-boot's command line for
three times.

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Acked-by: Minkyu Kang <mk7.kang@samsung.com>

kbuild: fix a bug in regeneration of linker scripts

In some use cases, SPL linker script was not updated even when
it should be.

For instance,

  $ make tricoder_config all
    [ build complete ]
  ... modify include/configs/tricoder.h
  $ make

spl/u-boot-spl.lds should be updated in this case, but it wasn't.

To fix this problem, linker scripts generation should be handled
by $(call if_changed_dep,...) rather than by $(call if_changed,...).

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Reported-by: Andreas Bießmann <andreas.devel@googlemail.com>
Tested-by: Andreas Bießmann <andreas.devel@googlemail.com>

Merge branch 'u-boot/master' into 'u-boot-arm/master'

Conflicts:
arch/arm/cpu/arm926ejs/mxs/Makefile
include/configs/trats.h
include/configs/trats2.h
include/mmc.h

arm64 patch: gicv3 support

This patch add gicv3 support to uboot armv8 platform.

Changes for v2:
  - rename arm/cpu/armv8/gic.S with arm/lib/gic_64.S
  - move smp_kick_all_cpus() from gic.S to start.S, it would be
    implementation dependent.
  - Each core initialize it's own ReDistributor instead of master
    initializeing all ReDistributors. This is advised by arnab.basu
    <arnab.basu@freescale.com>.

Signed-off-by: David Feng <fenghua@phytium.com.cn>

bootstage: arm: fix fdt stashing code

The conditional is using a variable that is not defined.

Signed-off-by: Rommel G Custodio <sessyargc+u-boot@gmail.com>

ARMv8: fix bug for flush data cache by set/way

When flush the d$ with set/way instruction, it need calculate the way's
offset = log2(Associativity); but in current uboot's code, it use below
formula to calculate the offset: log2(Associativity * 2 - 1), so finally
it cannot flush data cache properly.

Signed-off-by: Leo Yan <leoy@marvell.com>

armv8: Flush dcache before switching to EL2

For ARMv8, U-boot has been running at EL3 with cache and MMU enabled.
Without proper setup for EL2, cache and MMU are both disabled (out of
reset). Before switching, we need to flush the dcache to make sure the
data is in the main memory.

Signed-off-by: York Sun <yorksun@freescale.com>
Acked-by: David.Feng <fenghua@phytium.com.cn>

arm: vf610: fix double iomux configuration for vf610twr board

Get rid of double VF610_PAD_DDR_A15__DDR_A_15 iomux configuration.

Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>

arm: vf610: add enet1 support

This patch contains several changes required for second Ethernet
(enet1/RMII1) port on vf610
- ANADIG PLL5 control definitions required for Ethernet RMII1 clock
- Secondary Ethernet (enet1) MAC RMII1 base address definition
- RMII1 iomux definitions
- VF610_PAD_PTA6__RMII0_CLKOUT iomux definition required for
  internal (e.g. crystal-less) Ethernet clocking.

Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
[stefan@agner.ch: regrouped patch]
Signed-off-by: Stefan Agner <stefan@agner.ch>

arm: vf610: add uart0 clock/iomux definitions

Add CCM_CCGR0_UART0_CTRL_MASK clock definition and add TX/RX iomux
definitions for UART0 (aka. SCI0).

Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
[stefan@agner.ch: regrouped patch]
Signed-off-by: Stefan Agner <stefan@agner.ch>

arm: vf610: fix anadig register struct

The anadig_reg structure started at the wrong offset (fixed by adding
reserved_0x000[4]), was missing some reserved field required for
alignment purpose (reserved_0x094[3] between pll4_denom and pll6_ctrl)
and further contained a too short reserved field causing further miss-
alignment (reserved_0x0C4[7]). Also, rename all the reserved fields
and using a memory offset based scheme for.

Discovered and tested by temporarily putting the following debug
instrumentation into board_init():
    struct anadig_reg *anadig = (struct anadig_reg *)ANADIG_BASE_ADDR;
    printf("&anadig->pll3_ctrl=0x%p\n", &anadig->pll3_ctrl);
    printf("&anadig->pll5_ctrl=0x%p\n", &anadig->pll5_ctrl);

Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
[stefan@agner.ch: regrouped patch]
Signed-off-by: Stefan Agner <stefan@agner.ch>

build:arm: Remove setting of CROSS_COMPILE environment variable

After Kbuild introduction, the CROSS_COMPILE environment variable has been
set to some default value (prefix arm-linux-).

This shall be removed since it breaks building u-boot for native arm target
(like qemu ARM).
Moreover not all compilers have arm-linux- prefix.

Additionally the u-boot cross compiles with CROSS_COMPILE= set explicitly-
e.g.:
CROSS_COMPILE=/ .... /arm-v7a-linux-gnueabi- make

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Masahiro Yamada <yamada.m@jp.panasonic.com>

Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'

MX6: Enable ARM errata workaround 794072 and 761320

Since MX6 is Cortex-A9 r2p10, enable software workaround
for errata 794072 and 761320.

Signed-off-by: Nitin Garg <nitin.garg@freescale.com>

ARM: Add workaround for Cortex-A9 errata 761320

Full cache line writes to the same memory region from at least two
processors might deadlock the processor. Exists on r1, r2, r3
revisions.

Signed-off-by: Nitin Garg <nitin.garg@freescale.com>
Acked-by: Fabio Estevam <fabio.estevam@freescale.com>

ARM: Add workaround for Cortex-A9 errata 794072

A short loop including a DMB instruction might cause a denial of
service on another processor which executes a CP15 broadcast operation.
Exists on r1, r2, r3, r4 revisions.

Signed-off-by: Nitin Garg <nitin.garg@freescale.com>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>

armv8/cache: Change cache invalidate and flush function

When SoC first boots up, we should invalidate the cache but not flush it.
We can use the same function for invalid and flush mostly, with a wrapper.

Invalidating large cache can ben slow on emulator, so we postpone doing
so until I-cache is enabled, and before enabling D-cache.

Signed-off-by: York Sun <yorksun@freescale.com>
CC: David Feng <fenghua@phytium.com.cn>

armv8/cache: Flush D-cache, invalidate I-cache for relocation

If D-cache is enabled, we need to flush it, and invalidate i-cache before
jumping to the new location. This should be done right after relocation.

Signed-off-by: York Sun <yorksun@freescale.com>
CC: David Feng <fenghua@phytium.com.cn>

armv8/cache: Consolidate setting for MAIR and TCR

Move setting for MAIR and TCR to cache_v8.c, to avoid conflict with
sub-architecture.

Signed-off-by: York Sun <yorksun@freescale.com>
CC: David Feng <fenghua@phytium.com.cn>

arm: Handle .gnu.hash section in ldscripts

Avoids "could not find output section .gnu.hash" ld.bfd errors on openSUSE.

Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Tom Rini <trini@ti.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

socfpga: Adding Clock Manager driver

Clock Manager driver will be called to reconfigure all the
clocks setting based on user input. The input are passed to
Preloader through handoff files

Signed-off-by: Chin Liang See <clsee@altera.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Tom Rini <trini@ti.com>
Cc: Wolfgang Denk <wd@denx.de>
CC: Pavel Machek <pavel@denx.de>
Cc: Dinh Nguyen <dinguyen@altera.com>
Acked-by: Pavel Machek <pavel@denx.de>

Revert "Start the deprecation process for generic board"

We've run into a non-trivial conversion to CONFIG_SYS_GENERIC_BOARD so
we'll postpone this notice until right after v2014.04 is out.

This reverts commit 36c4b1d98059244c34ec3327d9cc9f3c552fd01b.

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

arm: mxs: Add support for generating signed BootStream

This patch adds the groundwork for generating signed BootStream, which
can be used by the HAB library in i.MX28. We are adding a new target,
u-boot-signed.sb , since the process for generating regular non-signed
BootStream is much easier. Moreover, the signed bootstream depends on
external _proprietary_ _binary-only_ tool from Freescale called 'cst',
which is available only under NDA.

To make things even uglier, the CST or HAB mandates a kind-of circular
dependency. The problem is, unlike the regular IVT, which is generated
by mxsimage, the IVT for signed boot must be generated by hand here due
to special demands of the CST. The U-Boot binary (or SPL binary) and IVT
are then signed by the CST as a one block. But here is the problem. The
size of the entire image (U-Boot, IVT, CST blocks) must be appended at
the end of IVT. But the size of the entire image is not known until the
CST has finished signing the U-Boot and IVT. We solve this by expecting
the CST block to be always 3904B (which it is in case two files, U-Boot
and the hand-made IVT, are signed in the CST block).

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>

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

Conflicts:
arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg

Signed-off-by: Stefano Babic <sbabic@denx.de>

Revert "arm: mxs: Add support for generating signed BootStream"

This reverts commit 53e6b14e037c9f72e6d03244c32d8d597e2e0234.

Patch does not merge anymore with u-boot-arm and must be rebased.

Signed-off-by: Stefano Babic <sbabic@denx.de>

trats/trats2: enable CONFIG_RANDOM_UUID

This change enables automatically uuid generation by command gpt.
In case of updating partitions layout user don't need to care about
generate uuid manually.

Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Piotr Wilczek <p.wilczek@samsung.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: trini@ti.com

cmd:gpt: randomly generate each partition uuid if undefined

Changes:
- randomly generate partition uuid if any is undefined and CONFIG_RAND_UUID
  is defined
- print debug info about set/unset/generated uuid
- update doc/README.gpt

Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Piotr Wilczek <p.wilczek@samsung.com>
Cc: Tom Rini <trini@ti.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>

new commands: uuid and guid - generate random unique identifier

Those commands basis on implementation of random UUID generator version 4
which is described in RFC4122. The same algorithm is used for generation
both ids but string representation is different as below.

char:  0        9    14   19   24         36
       xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
UUID:     be     be   be   be       be
GUID:     le     le   le   be       be

Commands usage:
- uuid [<varname>]
- guid [<varname>]

The result is saved in environment as a "varname" variable if argument is given,
if not then it is printed.

New config:
- CONFIG_CMD_UUID

Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: trini@ti.com

lib: uuid: add functions to generate UUID version 4

This patch adds support to generate UUID (Universally Unique Identifier)
in version 4 based on RFC4122, which is randomly.

Source: https://www.ietf.org/rfc/rfc4122.txt

Changes:
- new configs:
  - CONFIG_LIB_UUID for compile lib/uuid.c
  - CONFIG_RANDOM_UUID for functions gen_rand_uuid() and gen_rand_uuid_str()
- add configs dependency to include/config_fallbacks.h for lib uuid.

lib/uuid.c:
- add gen_rand_uuid() - this function writes 16 bytes len binary representation
  of UUID v4 to the memory at given address.

- add gen_rand_uuid_str() - this function writes 37 bytes len hexadecimal
  ASCII string representation of UUID v4 to the memory at given address.

Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
[trini: Add CONFIG_EFI_PARTITION to fallbacks]
Signed-off-by: Tom Rini <trini@ti.com>

lib: uuid: code refactor for proper maintain between uuid bin and string

Changes in lib/uuid.c to:
- uuid_str_to_bin()
- uuid_bin_to_str()

New parameter is added to specify input/output string format in listed functions
This change allows easy recognize which UUID type is or should be stored in given
string array. Binary data of UUID and GUID is always stored in big endian, only
string representations are different as follows.

String byte: 0                                  36
String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
string UUID:    be     be   be   be       be
string GUID:    le     le   le   be       be

This patch also updates functions calls and declarations in a whole code.

Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: trini@ti.com

part_efi: move uuid<->string conversion functions into lib/uuid.c

This commit introduces cleanup for uuid library.
Changes:
- move uuid<->string conversion functions into lib/uuid.c so they can be
  used by code outside part_efi.c.
- rename uuid_string() to uuid_bin_to_str() for consistency with existing
  uuid_str_to_bin()
- add an error return code to uuid_str_to_bin()
- update existing code to the new library functions.

Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: trini@ti.com

ahci: Fix data abort on multiple scsi resets.

Commit 2faf5fb82ed6 introduced a regression that causes a data
abort when running scsi init followed by scsi reset.

There are 2 problems with the original commit
1) ALLOC_CACHE_ALIGN_BUFFER() allocates memory on the stack but is
assigned to ataid[port] and used by other functions.
2) The function ata_scsiop_inquiry() tries to free memory which was
never allocated on the heap.

Fix these problems by using tmpid as a temporary cache aligned buffer.
Allocate memory separately for ataid[port] and re-use it if required.

Fixes: 2faf5fb82ed6 (ahci: Fix cache align error messages)

Reported-by: Eli Nidam <elini@marvell.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>

config:trats2: Change u-boot's TEXT_BASE from 0x78100000 to 0x43e00000

The u-boot's image TEXT_BASE needs to be changed to 0x43e00000 from 0x78100000.

This change provides compatibility with other trats2 (RD_PQ) devices
(http://download.tizen.org/releases/system/).

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

mmc:eSDHC: Workaround for data timeout issue on Txxx SoC

1. The Data timeout counter value in eSDHC_SYSCTL register is
not working as it should be, so add quirks to enable this
workaround to fix it to the max value 0xE.

2. Add CONFIG_SYS_FSL_ERRATUM_ESDHC111 to enable its workaround.

* Update of patch for change mmc interface by
Pantelis Antoniou <panto@antoniou-consulting.com>

Signed-off-by: Haijun Zhang <Haijun.Zhang@freescale.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>

mmc: fsl_esdhc: add controller reset in case of data related errors too

The controller reset is performed now if command error occurs.
This commit adds the reset for the case of data related errors too.

Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>

mmc: fsl_esdhc: fix calculation of timeout for data transactions

Calculation of the timeout value should be based on actual clock value,
written to controller registers. Since mmc->tran_speed is either the
maximum allowed speed, or the preliminary value, that is be not yet
set to registers, the actual timeout, taken by the controller, based
on its clock settings, may be much longer than expected, based on
mmc->tran_speed value. In particular it happens at early initialization
stage, when typical value of mmc->tran_speed is 20MHz or 26MHz, while
actual clock setting, configured in the controller, is 400kHz.
It's more correct to use mmc->clock value for timeout calculation instead.

Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>

mmc: Add 'mmc rst-function' sub-command

Some eMMC chips may need the RST_n_FUNCTION bit set to a non-zero value
in order for warm reset of the system to work.  Details on this being
required will be part of the eMMC datasheet.  Also add using this
command to the dra7xx README.

* Whitespace fix by panto

Signed-off-by: Tom Rini <trini@ti.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>

mmc: sh_mmcif: Fix warning by unused variable

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Reported-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>

mmc: sh_mmcif: Fix compile error

BY commit "mmc: Split mmc struct, rework mmc initialization (v2)",
sh_mmcif has compile error. This fixes compile error.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
CC: Pantelis Antoniou <panto@antoniou-consulting.com>
Reported-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>

mx6: add example DTB for mx6qsabreauto

Signed-off-by: Stefano Babic <sbabic@denx.de>
CC: Fabio Estevam <fabio.estevam@freescale.com>

imx: add rules for U-Boot DTB support

Signed-off-by: Stefano Babic <sbabic@denx.de>

mxs: fix warning in SPL with console support

Signed-off-by: Stefano Babic <sbabic@denx.de>

Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'

arm: mxs: Add serial console support into SPL

Add support for serial console into the i.MX23/i.MX28 SPL. A full,
uncrippled serial console support comes very helpful when debugging
various spectacular hardware bringup issues early in the process.
Because we do not use SPL framework, but have our own minimalistic
SPL, which is compatible with the i.MX23/i.MX28 BootROM, we do not
use preloader_console_init(), but instead use a similar function to
start the console. Nonetheless, to avoid blowing up the size of the
SPL binary, this support is enabled only if CONFIG_SPL_SERIAL_SUPPORT
is defined, which is disabled by default.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>

arm: mxs: Properly set GD pointer in SPL

Set the GD pointer in the SPL to a defined symbol so various
functions from U-Boot can be used without adverse side effects.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>

Prepare v2014.04-rc3

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

arm: mx5: Avoid hardcoding memory sizes on M53EVK

The DRAM size can be easily detected at runtime on i.MX53. Implement
such detection on M53EVK and adjust the rest of the macros accordingly
to use the detected values.

An important thing to note here is that we had to override the function
for trimming the effective DRAM address, get_effective_memsize(). That
is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of
the available DRAM and we don't have gd->bd->bi_dram[0].size set up at
the time the function is called, thus we cannot put this into the macro
CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the
size of the first DRAM block which we just detected.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>

arm: mx5: Fix memory slowness on M53EVK

Fix memory access slowness on i.MX53 M53EVK board. Let us inspect the
issue: First of all, the i.MX53 CPU has two memory banks mapped at
0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of
DRAM memory. Notice that the memory area is not continuous. On M53EVK,
each of the banks contain 512MiB of DRAM, which makes a total of 1GiB
of memory available to the system.

The problem is how the relocation of U-Boot is treated on i.MX53 . The
U-Boot is placed at the ((start of first DRAM partition) + (gd->ram_size)) .
This in turn poses a problem, since in our case, the gd->ram_size is 1GiB,
the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory.
Thus, with this algorithm, U-Boot is placed at offset:

    0x7000_0000 + 1GiB - sizeof(u-boot and some small margin)

This is past the DRAM available in the first bank on M53EVK, but is still
within the address range of the first DRAM bank. Because of the memory
wrap-around, the data can still be read and written to this area, but the
access is much slower.

There were two ideas how to solve this problem, first was to map both of
the available DRAM chunks next to one another by using MMU, second was to
define CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED to size of the memory
in the first DRAM bank. We choose the later because it turns out the former
is not applicable afterall. The former cannot be used in case Linux kernel
was loaded into the second DRAM bank area, which would be remapped and one
would try booting the kernel, since at some point before the kernel is started,
the MMU would be turned off, which would destroy the mapping and hang the
system.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>

arm: mx5: Avoid hardcoding memory sizes on MX53QSB

The DRAM size can be easily detected at runtime on i.MX53. Implement
such detection on MX53QSB and adjust the rest of the macros accordingly
to use the detected values.

An important thing to note here is that we had to override the function
for trimming the effective DRAM address, get_effective_memsize(). That
is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of
the available DRAM and we don't have gd->bd->bi_dram[0].size set up at
the time the function is called, thus we cannot put this into the macro
CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the
size of the first DRAM block which we just detected.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>

arm: mx5: Fix memory slowness on MX53QSB

Fix memory access slowness on i.MX53 MX53QSB board. Let us inspect the
issue: First of all, the i.MX53 CPU has two memory banks mapped at
0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of
DRAM memory. Notice that the memory area is not continuous. On MX53QSB,
each of the banks contain 512MiB of DRAM, which makes a total of 1GiB
of memory available to the system.

The problem is how the relocation of U-Boot is treated on i.MX53 . The
U-Boot is placed at the ((start of first DRAM partition) + (gd->ram_size)) .
This in turn poses a problem, since in our case, the gd->ram_size is 1GiB,
the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory.
Thus, with this algorithm, U-Boot is placed at offset:

    0x7000_0000 + 1GiB - sizeof(u-boot and some small margin)

This is past the DRAM available in the first bank on MX53QSB, but is still
within the address range of the first DRAM bank. Because of the memory
wrap-around, the data can still be read and written to this area, but the
access is much slower.

There were two ideas how to solve this problem, first was to map both of
the available DRAM chunks next to one another by using MMU, second was to
define CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED to size of the memory
in the first DRAM bank. We choose the later because it turns out the former
is not applicable afterall. The former cannot be used in case Linux kernel
was loaded into the second DRAM bank area, which would be remapped and one
would try booting the kernel, since at some point before the kernel is started,
the MMU would be turned off, which would destroy the mapping and hang the
system.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>

ARM: mx6: Add PCIe on SabreSDP

Add support for PCIe on MX6 SabreSDP board and enable the support
in the config file.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Liu Ying <Ying.Liu@freescale.com>

pci: mx6: Implement power callback

Implement a callback to toggle the slot power supply. The callback
can be overriden in case some more complex power supply for the slot
was implemented in hardware, yet for the usual case, one can define
a GPIO which toggles the power to the slot.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Liu Ying <Ying.Liu@freescale.com>

ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x

Use of PCIe on SABRE Lite and Nitrogen6x boards
is atypical and requires the use of custom daughter
boards.

Use in U-Boot is even rarer, so this patch removes it from
the standard configuration.

Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Acked-by: Marek Vasut <marex@denx.de>

woodburn_sd: Remove CONFIG_BOOT_INTERNAL

CONFIG_BOOT_INTERNAL is not used anywhere, so let's remove it.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Stefano Babic <sbabic@denx.de>

ARM: mxs: Add OCOTP driver

Add yet another OCOTP driver for this i.MX family. This time, it's a driver for
the OCOTP variant found in the i.MX23 and i.MX28. This version of OCOTP is too
different from the i.MX6 one that I could not use the mxc_ocotp.c driver without
making it into a big pile of #ifdef . This driver implements the regular fuse
command interface, but due to the IP blocks' limitation, we support only READ
and PROG functions.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>

arm: mxs: Add support for generating signed BootStream

This patch adds the groundwork for generating signed BootStream, which
can be used by the HAB library in i.MX28. We are adding a new target,
u-boot-signed.sb , since the process for generating regular non-signed
BootStream is much easier. Moreover, the signed bootstream depends on
external _proprietary_ _binary-only_ tool from Freescale called 'cst',
which is available only under NDA.

To make things even uglier, the CST or HAB mandates a kind-of circular
dependency. The problem is, unlike the regular IVT, which is generated
by mxsimage, the IVT for signed boot must be generated by hand here due
to special demands of the CST. The U-Boot binary (or SPL binary) and IVT
are then signed by the CST as a one block. But here is the problem. The
size of the entire image (U-Boot, IVT, CST blocks) must be appended at
the end of IVT. But the size of the entire image is not known until the
CST has finished signing the U-Boot and IVT. We solve this by expecting
the CST block to be always 3904B (which it is in case two files, U-Boot
and the hand-made IVT, are signed in the CST block).

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>

arm: mxs: Adjust the load address of U-Boot and SPL for HAB

When using HAB, there are additional special requirements on the placement of
U-Boot and the U-Boot SPL in memory. To fullfill these, this patch moves the
U-Boot binary a little further from the begining of the DRAM, so the HAB CST
and IVT can be placed in front of the U-Boot binary. This is necessary, since
both the U-Boot and the IVT must be contained in single CST signature. To
make things worse, the IVT must be concatenated with one more entry at it's
end, that is the length of the entire CST signature, IVT and U-Boot binary
in memory. By placing the blocks in this order -- CST, IVT, U-Boot, we can
easily align them all and then produce the length field as needed.

As for the SPL, on i.MX23/i.MX28, the SPL size is limited to 32 KiB, thus
we place the IVT at 0x8000 offset, CST right past IVT and claim the size
is correct. The HAB library accepts this setup.

Finally, to make sure the vectoring in SPL still works even after moving
the SPL from 0x0 to 0x1000, we add a small function which copies the
vectoring code and tables to 0x0. This is fine, since the vectoring code
is position independent.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>