Start using the new Kconfig options which are available for these now,
and simply always enable them by selecting them as sunxi builds always
include USB support.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NIan Campbell <ijc@hellion.org.uk>
Reviewed-by: NSimon Glass <sjg@chromium.org>

With certain features being convert to DM now we want sunxi to default
to having DM enabled for ETH/SERIAL and USB in some cases.

Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: NTom Rini <trini@konsulko.com>
[hdegoede@redhat.com: Also select CONFIG_USB for all sunxi builds]
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NIan Campbell <ijc@hellion.org.uk>
Reviewed-by: NSimon Glass <sjg@chromium.org>

At one point in time the utoo-p66 dts file in the kernel had a bogus
uart entry, and it seems like we synced with the kernel at just the wrong
moment.

This commit removes the bogus uart entry, which breaks booting the utoo-p66
when DM_SERIAL=y.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Remove the boot signature check from board_mmc_init() in spl mode, as it
is already done in spl_boot_device() in this case, and update the comments
to reflect this.
Signed-off-by: NDaniel Kochmański <dkochmanski@turtle-solutions.eu>
CC: Roy Spliet <r.spliet@ultimaker.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
[hdegoede@redhat.com: Disable the check only for SPL instead of always]
Acked-by: NHans De Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Make possible using a single `u-boot-sunxi-with-spl.bin` binary for both NAND
memory and SD card. Detection where SPL was read from is implemented in
`spl_boot_device`.
Signed-off-by: NDaniel Kochmański <dkochmanski@turtle-solutions.eu>
CC: Roy Spliet <r.spliet@ultimaker.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
[hdegoede@redhat.com: Some small coding style fixes]
Acked-by: NHans De Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

This patch extracts checking for valid SD card "eGON.BT0" signature from
`board_mmc_init` into function `sunxi_mmc_has_egon_boot_signature`.

Buffer for mmc sector is allocated and freed at runtime. `panic` is
triggered on malloc failure.
Signed-off-by: NDaniel Kochmański <dkochmanski@turtle-solutions.eu>
CC: Roy Spliet <r.spliet@ultimaker.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
[hdegoede@redhat.com: Small bugfix to make it work for devs other then mmc0]
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

`mmc_initialize` might be called multiple times leading to the mmc-controllers
being initialised twice, and initialising the `mmc_devices` list head twice
which may lead to memory leaks.
Signed-off-by: NDaniel Kochmański <dkochmanski@turtle-solutions.eu>
CC: Roy Spliet <r.spliet@ultimaker.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
CC: Pantelis Antoniou <panto@antoniou-consulting.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

This I2C device is used SoC-internally for controlling the DMD core.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

The init code for UMC (Unified Memory Controller) and PLL has not
been mainlined yet, but U-boot proper should work.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Both "earlyprintk" and "loglevel=8" should be useful for the
development.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

To use FIT boot, we have to describe Image Tree Source in addition.
So, it is not intended for beginners.  Disable it by default.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

The command "run tftpboot" downloads some files onto the RAM
via TFTP and boots the kernel.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Currently, the environment variables "norboot" and "nandboot" only
work with CONFIG_FIT, but we do not want to depend on CONFIG_FIT to
boot the kernel.

This commit adds environments useful for booting Linux with separate
uImage + ramdisk + DTB.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

For the record, describe exactly which device of which vendor
is used on this board.

I2C EEPROM is bound by the generic compatible string, "i2c-eeprom",
so this commit has no impact on the functionality.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

This patch adds SPL support for the Marvell DB-88F6820-GP board.
With this change, the bin_hdr from the original Marvell U-boot
is not needed any more on this board. The sources from bin_hdr
(SERDES/PHY and DDR setup) are now integrated in mainline
U-Boot. And this patch enables them for this board.
Signed-off-by: NStefan Roese <sr@denx.de>

Remove the incorrect PEX macros from the DDR header. And insert the
correct ones in ctrl_pex.h instead.
Signed-off-by: NStefan Roese <sr@denx.de>

This patch adds the DDR3 setup and training code taken from the Marvell
U-Boot repository. This code used to be included as a binary (bin_hdr)
into the Armada A38x boot image. Not linked with the main U-Boot. With this
code addition and the serdes/PHY setup code, the Armada A38x support
in mainline U-Boot is finally self-contained. So the complete image
for booting can be built from mainline U-Boot. Without any additional
external inclusion.

Note:
This code has undergone many hours (days!) of coding-style cleanup and
refactoring. It still is not checkpatch clean though, I'm afraid. As the
factoring of the code has so many levels of indentation that many lines
are longer than 80 chars.
Signed-off-by: NStefan Roese <sr@denx.de>

With the upcoming addition of the Armada 38x DDR support, which is not
compatible to the Armada XP DDR init code, we need to introduce a new
directory infrastructure. To support multiple Marvell DDR controller.

This will be the new structure:

     drivers/ddr/marvell/axp
     Supporting Armada XP (AXP) devices (and perhaps Armada 370)

     drivers/ddr/marvell/a38x
     Supporting Armada 38x devices (and perhaps Armada 39x)
Signed-off-by: NStefan Roese <sr@denx.de>

This code is ported from the Marvell bin_hdr code into mainline
SPL U-Boot. It needs to be executed very early so that the devices
connected to the serdes PHY are configured correctly.
Signed-off-by: NStefan Roese <sr@denx.de>

With the upcoming addition of the Armada 38x SPL support, which is not
compatible to the Armada XP SERDES init code, we need to introduce a new
directory infrastructure. So lets move the AXP serdes init code into
a new directory. This way the A38x code can be added in a clean way.
Signed-off-by: NStefan Roese <sr@denx.de>

The u-boot-spl.kwb build target needs the SPL text-base
(CONFIG_SPL_TEXT_BASE) as load and execution address.
Signed-off-by: NStefan Roese <sr@denx.de>

Only with disabled MMU its possible to switch the base register address on
Armada 38x. Without this the SDRAM located at >= 0x4000.0000 is also not
accessible, as its still locked to cache.
Signed-off-by: NStefan Roese <sr@denx.de>

Pin muxing needs to be done before UART output, since on A38x the UART
pins need some re-muxing for output to work.
Signed-off-by: NStefan Roese <sr@denx.de>

On A38x switching the regs base address without running from
SDRAM doesn't seem to work. So let the SPL still use the
default base address and switch to the new address in the
mail u-boot later.
Signed-off-by: NStefan Roese <sr@denx.de>

Without calling timer_init(), the xdelay() functions return immediately.
We need to call timer_init() early, so that these functions work and
the PHY and DDR init code works correctly.
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Anton Schubert <anton.schubert@gmx.de>
Cc: Luka Perkov <luka.perkov@sartura.hr>

This patch initializes the SATA address windows on Armada XP and
allows it to work with the existing mvsata_ide driver.
It also adds the necessary configuration for the db-mv784mp-gp board.
Signed-off-by: NAnton Schubert <anton.schubert@gmx.de>
Tested-by: NStefan Roese <sr@denx.de>
Cc: Luka Perkov <luka.perkov@sartura.hr>

Currently, kzalloc() returns zero-filled memory, while kmalloc()
simply ignores the second argument and never fills the memory
area with zeros.

I want kmalloc(size, __GFP_ZERO) to behave as kzalloc() does,
which will make it easier to add more memory allocator variants.

With the introduction of __GFP_ZERO flag, going forward, kzmalloc()
variants can fall back to kmalloc() enabling the __GFP_ZERO flag.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>
Acked-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NLukasz Majewski <l.majewski@samsung.com>

The vzalloc(size) is equivalent to kzalloc(size, 0).  Move it to
include/linux/compat.h as an inline function in order to avoid the
function call overhead.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>
Acked-by: NSimon Glass <sjg@chromium.org>

The macro cpu_relax() is defined by several headers in different
ways.

arch/{arm,avr32,mips}/include/asm/processor.h defines it as follows:
  #define cpu_relax()	barrier()

On the other hand, include/linux/compat.h defines it as follows:
  #define cpu_relax() do {} while (0)

If both headers are included from the same source file, the warning
  warning: "cpu_relax" redefined [enabled by default]
is displayed.

It effectively makes it impossible to include <linux/compat.h>
from some sources.  Drop the latter.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>
Acked-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NLukasz Majewski <l.majewski@samsung.com>

These two declarations in arch/x86/include/asm/interrupt.h conflict
with ones in include/linux/compat.h, so x86 boards cannot include
<linux/compat.h>.

The comment /* arch/x86/lib/interrupts.c */ is bogus now, and we do
not see any definitions of disable_irq() and enable_irq() in there.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Some drivers may want to implement this method for some of their devices but
not for others. So it is not possible to just leave the operation out of
the table. Drivers could get around this by masquerading as two separate
drivers but that seems unpleasant.

Allow the driver to return an error when it does not want to process the
write_hwaddr() method.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This USB Ethernet driver is quite widely use. Allow it to work with
CONFIG_DM_ETH enabled. Most of the code remains common but there is a new
packet receive flow which is handled specially.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Support driver model in this driver. This uses the normal USB driver search
mechanism. Any EHCI controllers will be set up as they are found during
usb_init().
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NMarek Vasut <marex@denx.de>

Now that the RTL8169 driver warning is fixed we can drop this. The incorrect
value is causing problems with USB EHCI.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

In Linux USB_DEVICE() is used to declare a USB device by vendor/device ID.
We should follow the same convention in U-Boot. Rename the existing
USB_DEVICE() macro to U_BOOT_USB_DEVICE() and bring in the USB_DEVICE()
macro from Linux for use in U-Boot.
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present USB Ethernet does not work with CONFIG_DM_ETH. Add driver model
support to this feature, so that it can work alongside other Ethernet
devices with driver model.

It was found that quite a bit of code is common in most of the USB Ethernet
drivers. Add this code to the common layer to reduce the amount of duplicate
code needed in USB Ethernet drivers when CONFIG_DM_ETH is used.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NMarek Vasut <marex@denx.de>

Some devices can take a long time to work out whether they have a new packet
or now. For example the ASIX USB Ethernet dongle can take 5 seconds to do
this, since it waits until it gets a new packet on the wire before allowing
the USB bulk read packet to be submitted.

At present with driver mode the Ethernet receive code reads 32 packets. This
can take a very long time if we must wait for all 32 packets. The old code
(before driver model) worked by reading a single set of packets from the USB
device, then processing all the packets with in. It would be nice to use
the same behaviour with driver model.

Add a flag to the receive method which indicates that the driver should try
to find a packet if available, by consulting the hardware. When the flag is
not set, it should just return any packet data it has already received. If
there is none, it should return -EAGAIN so that the loop will terminate.
Signed-off-by: NSimon Glass <sjg@chromium.org>