This device uses SDHCI driver, for eMMC and SD cards.
Trying bind the DW MMC driver with fdt node without all
required properties, causes printing an error.

This commit disables the DW MMC node.

Tested-on: Trats
Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
Cc: Łukasz Majewski <l.majewski@samsung.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>

After rework of code by:

commit: d9527968 Exynos5: Use clock_get_periph_rate generic API

function get_mmc_clk() always returns -1 for Exynos 4.

This was caused by omitting, that SDHCI driver for Exynos 4,
calls get_mmc_clk(), with mmc device number as argument,
instead of pinmux peripheral id, like DW MMC driver for Exynos 5.

By this commit, the code directly calls a proper function
to get mmc clock for Exynos 4, without checking the peripheral id.

Tested on: Odroid U3/X2, Trats, Trats2, Odroid XU3, Snow (by Simon).
Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NSimon Glass <sjg@chromium.org>
Tested-by: NSimon Glass <sjg@chromium.org>

After rework in lib/fdtdec.c, the function fdtdec_get_addr()
doesn't work for nodes with #size-cells property set to 0.

To get GPIO's 'reg' property, the code should use one of:
fdtdec_get_addr_size_auto_no/parent() function.

Fortunately dm core provides a function to get the property.

This commit reworks function gpio_exynos_bind(), to properly
use dev_get_addr() for GPIO device.

This prevents setting a wrong base register for Exynos GPIOs.

Tested on: Odroid U3/X2, Trats, Trats2, Odroid XU3, Snow (by Simon).
Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NSimon Glass <sjg@chromium.org>
Tested-by: NSimon Glass <sjg@chromium.org>

After rework of lib/fdtdec.c by:

commit: 02464e38 fdt: add new fdt address parsing functions

the function fdtdec_get_addr() doesn't work as previous,
because the implementation assumes that properties '#address-cells'
and '#size-cells' are equal to 1, which can be not true sometimes.

The new API introduced fdtdec_get_addr_size_auto_parent() for the 'reg'
property parsing, but the implementation assumes, that #size-cells
can't be less than 1.

This causes that the following children's 'reg' property can't be reached:

parent@0x0 {
     #address-cells = <1>;
     #size-cells = <0>;
     children@0x100 {
         reg = < 0x100 >;
     };
};

Change the condition value from '1' to '0', which allows parsing property
with at least zero #size-cells, fixes the issue.

Now, fdtdec_get_addr_size_auto_parent() works properly.

Tested on: Odroid U3/X2, Trats, Trats2, Odroid XU3, Snow (by Simon).
Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NSimon Glass <sjg@chromium.org>
Tested-by: NSimon Glass <sjg@chromium.org>

fdtdec_get_addr_size() may be used in two cases:
a) With sizep supplied, in which case both an address and a size are
parsed from DT. In this case, the DT property must be large enough to
contain both values.
b) With sizep NULL, in which case only an address is parsed from DT.
In this case, the DT property only need be large enough to contain this
address value. Commit 02464e38 "fdt: add new fdt address parsing
functions" broke this relaxed checking, and required the DT property to
contain both an address and a size value in all cases.

Fix fdtdec_get_addr_size() to vary ns based on whether the size value
is being parsed from the DT or not. This is safe since the function only
parses the first entry in the property, so the overall value of (na + ns)
need not be accurate, since it is never used to step through the property
data to find other entries. Besides, this fixed behaviour essentially
matches the original behaviour before the patch this patch fixes. (The
original code validated that the property was exactly the length of
either na or (na + ns), whereas the current code only validates that the
property is at least that long. For non-failure cases, the two behaviours
are identical).

Cc: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Michal Suchanek <hramrach@gmail.com>
Fixes: 02464e38 ("fdt: add new fdt address parsing functions")
Reported-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
Acked-by: NSimon Glass <sjg@chromium.org>

This comment from README.fdt-control did not end up in the Kconfig, which
is what most people will see. Add it with a few tweaks.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Acked-by: NMichal Simek <michal.simek@xilinx.com>

The 7" Q8 tablet enclosure is used for a ton of slightly different cheap
chinese tablets. There are some differences in which accelerometer /
wifi is used, but other then that these are all the same from a u-boot /
kernel pov.

When we get to adding accelerometer support the plan is to add some kind
of autodetection and mangle the dt accordingly (likely using the new quirks
mechanism).

For now this is a non issue as we do not yet have accelerometer
support, and in the future, some sort of auto-detect is the way to go
as we cannot expect users to exactly know what is inside their tablet.

The dts files this commit adds are identical to the ones submitted
to the upstream kernel.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NIan Campbell <ijc@hellion.org.uk>

In order to make it clear what the parameters to set_config() and
set_direction() mean, and similarly for the return values from the
respective get_*(), define named constants for these values.

Disassembly shows no diff in the generated code, except that the
order of the code in the branches of tegra_gpio_get_function() gets
modified without affecting behaviour.
Suggested-by: NTom Warren <twarren@nvidia.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

These enum values aren't used anywhere. Remove them.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NTom Warren <twarren@nvidia.com>

The size allocation for SPL is increased in all cases to match the
already-expanded value used on Tegra124. This is both for general
consistency, and because the seaboard build trips over the limit already
when using one of the ARM compilers packaged with 14.04. For the record,
when building Seaboard:

arm-linux-gnueabi- SPL is too big by 0x36 bytes
arm-linux-gnueabihf- SPL fits by 0x2a bytes
arm-none-eabi- SPL fits by 0xa bytes

(Those figures are from builds with the expanded SPL size allocation,
relative to the non-expanded SPL size limit; they're better by about
6 bytes in the more constrained build.)

Fixes: ba521994 ("tegra124: Expand SPL space by 8KB")
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

Tegra's GPIO driver currently enables pins as GPIO as soon as they're
requested. This is not safe, since the desired direction and output value
are not yet known. This could cause a glitch on the output pins between
gpio_request() and gpio_direction_*(), depending on what values happen to
be in the GPIO controller's in/out and out-value registers vs. the final
desired configuration.

To solve this, defer enabling pins as GPIOs until some gpio_direction_*()
is invoked, and the desired configuration is explicitly programmed.

In theory this change could cause regressions, if code exists that claims
a GPIO, never explicitly sets a direction, and then gets/sets the GPIO
value based on that assumption. However, I've read through all the Tegra-
related board files and device drivers that touch GPIOs and I do not see
such buggy code anywhere.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NTom Warren <twarren@nvidia.com>

Tegra's gpio_config_table() currently uses common GPIO APIs. These used
to work without requesting the GPIO, but since commit 2fccd2d9 "tegra:
Convert tegra GPIO driver to use driver model" no longer do so. This
prevents any of the GPIO initialization table from being applied to HW.
Fix gpio_config_table() to directly program the HW to solve this.

Fixes: 2fccd2d9 ("tegra: Convert tegra GPIO driver to use driver model")
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NTom Warren <twarren@nvidia.com>

In order to avoid any assumptions about any device connected to
P2371-2180's expansion connector, the latest pinmux spreadsheet
configures all muxable pins on that connector to be GPIO inputs, with
on-chip pulls where appropriate.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NTom Warren <twarren@nvidia.com>

Add DFU support.

Tested by flashing SPL and u-boot.img into SPI NOR flash with the
following commands:

=> setenv dfu_alt_info ${dfu_alt_info_spl}

=> run dfuspi

On the host PC:

$ sudo dfu-util -D SPL -a spl

On the target:

CTRL+C
=> setenv dfu_alt_info ${dfu_alt_info_img}

=> run dfuspi

On the host PC:

$ sudo dfu-util -D u-boot.img -a u-boot
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>

Devices supported are:
- NFC (NAND FLASH)
- MMC
- QSPI (SPI NOR FLASH)
- I2C (only bus 2)
- I2C RTC
- I2C EEPROM
- FEC

Patch-series: 2
- remove useless CONFIG_SYS_SPD_BUS_NUM from config
- remove include of config_cmd_default.h
- remove duplicate CONFIG_CMD_NET
Signed-off-by: NAlbert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>

The driver assumed that I2C1 and I2C2 were always enabled,
and if they were not, then an asynchronous abort was (silently)
raised, to be caught much later on in the Linux kernel.

Fix this by making I2C1 and I2C2 optional just like I2C3 and I2C4
are.

To make the change binary-invariant, declare I2C1 and I2C2 in
every include/configs/ file which defines CONFIG_SYS_I2C_MXC.

Also, while updating README about CONFIG_SYS_I2C_MXC_I2C1 and
CONFIG_SYS_I2C_MXC_I2C2, add missing descriptions for I2C4 speed
(CONFIG_SYS_MXC_I2C4_SPEED) and slave (CONFIG_SYS_MXC_I2C4_SLAVE)
config options.
Signed-off-by: NAlbert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>

The VF610 DDRMC driver code contains settings which are
board-specific. Move these out to boards so that new boards
can define their own without having to modify the driver.
Signed-off-by: NAlbert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>

Set missing boot address in bootm command. This fixes the error:
 Wrong Image Format for bootm command
 ERROR: can't get kernel image!
Reported-by: NUwe Scheffler <scheffler.u@web.de>
Signed-off-by: NSoeren Moch <smoch@web.de>
Tested-by: NUwe Scheffler <scheffler.u@web.de>

We should follow 'read->set/clr bit->write' flow for enable_fec_anatop_clock,
otherwise we may overridden configuration before enable_fec_anatop_clock.
Signed-off-by: NPeng Fan <Peng.Fan@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Cc: Fabio Estevam <fabio.estevam@freescale.com>

- add CONFIG_BOOT_RETRY_TIME to 30
- fex LED colors
- fix button pressed combination
- add
  CONFIG_USB_HOST_ETHER
  CONFIG_USB_ETHER_ASIX
  CONFIG_USB_ETHER_MCS7830
Signed-off-by: NHeiko Schocher <hs@denx.de>
Signed-off-by: NMatthias Michel <matthias.michel@siemens.com>

If defined CONFIG_ENV_IS_IN_MMC, then u-boot environment is saved in
mmc's raw sectors. Otherwise, u-boot environment is saved as a file:
uboot.env.
Signed-off-by: NJosh Wu <josh.wu@atmel.com>
Reviewed-by: NBo Shen <voice.shen@gmail.com>

Currently, kwboot only allows dynamic UART boot mode patching for SoCs
with header version 0 (Orion, Kirkwood). This patch now enables this "-p"
feature also for SoCs with header version 1 (Armada XP / 38x etc). With
this its possible now to use the UART boot mode without on images that
are generated for other boot devices, like SPI. So no need to change
BOOT_FROM to "uart" for UART xmodem booting any more.
Signed-off-by: NStefan Roese <sr@denx.de>
Tested-by: NKevin Smith <kevin.smith@elecsyscorp.com>
Cc: Luka Perkov <luka.perkov@sartura.hr>
Cc: Dirk Eibach <eibach@gdsys.de>

As reported by Simon Guinot, commit ade741b3
"arm: mvebu: Call timer_init early before PHY and DDR init" breaks
Kirkwood platforms. As the static variable "init_done" is not
available at that early boot time. This patch moves it to explicitly
to the data section, making it available at that time.
Signed-off-by: NStefan Roese <sr@denx.de>
Reported-by: NSimon Guinot <simon.guinot@sequanux.org>
Cc: Luka Perkov <luka.perkov@sartura.hr>
Tested-by: NSimon Guinot <simon.guinot@sequanux.org>

Currently booting on A38x is broken. As the current code tries to detect
the SoC family to disable the MMU for the A38x at runtime. But before the
internal registers are switched to the new location (0xf100.0000), this
runtime detection does not work. As all macros / defines are already
assigned to the new location at 0xf100.0000. But the registers are sill
mapped to the default location at 0xd000.0000.

This patch now makes sure, no such runtime detection is used before
the internal registers are configured to the new location. After this,
the remaining cache cleanup is executed.
Signed-off-by: NStefan Roese <sr@denx.de>
Reported-by: NKevin Smith <kevin.smith@elecsyscorp.com>
Cc: Luka Perkov <luka.perkov@sartura.hr>

Simon Glass and Joe Hershberger suggested adding at least one
test case for the CONFIG_DM_ETH plus CONFIG_NETCONSOLE options.

This patch enables NetConsole as a default for the "Banana Pi/Pro"
sunxi boards.

(By the nature of this patch it could probably be extended later
to include all sunxi boards using CONFIG_SUNXI_[EG]MAC.)
Signed-off-by: NBernhard Nortmann <bernhard.nortmann@web.de>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

This patch introduces CONFIG_NETCONSOLE as an option to the
Kconfig system.

Joe Hershberger pointed out that it may not be entirely free of
problems, as many boards predating the driver model define this
symbol directly via include files. In case they're not properly
migrated, their NetConsole might 'vanish' if they start to use
CONFIG_NET or CONFIG_NETDEVICES.
Signed-off-by: NBernhard Nortmann <bernhard.nortmann@web.de>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

CONFIG_NETCONSOLE causes common/bootm.c to call eth_unregister()
for network device shutdown. However, with CONFIG_DM_ETH this
function is no longer defined.

This is a workaround to avoid the call in that case, and solely
rely on eth_halt(). In case this is insufficient, a proper way
to unregister / remove network devices needs to be implemented.
Signed-off-by: NBernhard Nortmann <bernhard.nortmann@web.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

This patch uses the eth_is_active() function to work around
issues that prevented compilation with the newer driver model.
Signed-off-by: NBernhard Nortmann <bernhard.nortmann@web.de>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

The previous eth_device struct returned by eth_get_dev() allowed
code to directly query the state member field. However, with
CONFIG_DM_ETH this data gets encapsulated (i.e. private), and
eth_get_dev() returns a udevice struct 'abstraction' instead.

This breaks legacy code relying on the former behaviour - e.g.
netconsole.
(see http://lists.denx.de/pipermail/u-boot/2015-June/216528.html)

The patch introduces a method to retrieve the ethernet device
state in a 'clean' and uniform way, supporting both legacy code
and driver model. The new function eth_is_active() accepts a
device struct pointer and tests it for ETH_STATE_ACTIVE.
Signed-off-by: NBernhard Nortmann <bernhard.nortmann@web.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Currently when phy device is created the link variable is
initialized to 1 which denoted phy link is already up. On a power
reset there is no issue as phy status register link status will
not be set, so phy auto negotiate will be started. But when a cpu
reset is issued (ex: dra72x-evm) phy's link status bit is already
set which leads to assume that link is already setup in
genphy_update_link() initial check which results in ehternet not
working. So do not assume that link is already up and on phy
device create set link to zero. This is verified on dra72x-evm.
Reported-by: NFranklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

The 7" Q8 tablet enclosure is used for a ton of slightly different cheap
chinese tablets. There are some differences in which accelerometer /
wifi is used, but other then that these are all the same from a u-boot /
kernel pov.

When we get to adding accelerometer support the plan is to add some kind
of autodetection and mangle the dt accordingly (likely using the new quirks
mechanism).

For now this is a non issue as we do not yet have accelerometer
support, and in the future, some sort of auto-detect is the way to go
as we cannot expect users to exactly know what is inside their tablet.

The dts[i] files this commit adds are identical to the ones submitted
to the upstream kernel.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NIan Campbell <ijc@hellion.org.uk>

In recent allwinner kernel sources the mmc/sdio clk-delay settings have
been slightly tweaked, and for sun9i they are completely different then
what we are using.

This commit brings us in sync with what allwinner does, fixing problems
accessing sdcards on some A33 devices (and likely others).

For pre sun9i hardware this makes the following changes:
-At 400Khz change the sample delay from 7 to 0 (first introduced in A31 sdk)
-At 50 Mhz change the sample delay from 5 to 4 (first introduced in A23 sdk)
-Above 50 MHz change the out delay from 2 to 1 (first introduced in A20 sdk)
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NIan Campbell <ijc@hellion.org.uk>

We know when u-boot is written to its own partition, in this case the
layout always is:

eb 0 spl
eb 1 spl-backup
eb 2 u-boot
eb 3 u-boot-backup

eb: erase-block

So if we cannot load u-boot from its primary offset we know exactly where
to look for it.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NIan Campbell <ijc@hellion.org.uk>