Enable CONFIG_USB_ETHER_RTL8152 support for Odroid XU4 which
has support for RTL8153-CG gigabit Ethernet adapter,
connected over USB 3.0.

commit 9dc8ba19c50fc0b1623c654bcfe6caa903a4c36c added support
for Realtek 8152/8153 driver.

Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

When running sandbox, the following phases occur, each with different
malloc implementations or behaviors:

1) Dynamic linker execution, using the dynamic linker's own malloc()
implementation. This is fully functional.

2) After U-Boot's malloc symbol has been hooked into the GOT, but before
any U-Boot code has run. This phase is entirely non-functional, since
U-Boot's gd symbol is NULL and U-Boot's initf_malloc() and
mem_malloc_init() have not been called.

At least on Ubuntu Xenial, the dynamic linker does make both malloc() and
free() calls during this phase. Currently these free() calls crash since
they dereference gd, which is NULL.

U-Boot itself makes no use of malloc() during this phase.

3) U-Boot execution after gd is set and initf_malloc() has been called.
This is fully functional, albeit via a very simple malloc()
implementation.

4) U-Boot execution after mem_malloc_init() has been called. This is fully
functional with a complete malloc() implementation.

Furthermore, if code that called malloc() during phase 1 calls free() in
phase 3 or later, it is likely that heap corruption will occur, since
U-Boot's malloc implementation will assume the pointer is part of its own
heap, although it isn't. I have not actively observed this happening.

To prevent phase 2 from happening, this patch makes all of U-Boot's malloc
library public symbols have hidden visibility. This prevents them from
being hooked into the GOT, so only code in the U-Boot binary itself
actually calls them; any other code will call into the standard C library
malloc(). This also avoids the "furthermore" issue mentioned above.

I have seen references to this GCC pragma in blog posts from 2008, and
RHEL5's ancient gcc appears to accept it fine, so I believe it's quite
safe to use it without checking gcc version.

Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

- Add required UBI/UBIFS config definitions
- Add reasonable MTD partition layout
- Remove JFFS2 config definitions
- Drop some CFI verbage and definitions
- Make comment 'one-liners' truly one line
- Improve readability and content arrangement

Signed-off-by: Derald D. Woods <woods.technical@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Select 8-bit BCH ecc-scheme with s/w based error correction
- OMAP_ECC_BCH8_CODE_HW_DETECTION_SW

Signed-off-by: Derald D. Woods <woods.technical@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Move to booting a zImage kernel by default to align with the other
i.MX boards.

While at it, adjust the fdt_addr so that we can boot a standard
mainline kernel.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>

"fastboot oem format" command reuses "gpt write" command, which in turn
requires correct partitions defined in $partitions variable. This patch
adds such definition of Android partitions for DRA7XX EVM board.

By default $partitions variable contains Linux partition table. In order
to prepare Android environment one can run next commands from U-Boot
shell:

    => env set partitions $partitions_android
    => env save

After those operations one can go to fastboot mode and perform
"fastboot oem format" to create Android partition table.

While at it, enable CONFIG_RANDOM_UUID to spare user from providing
UUIDs for each partition manually.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

This introduces some minor cleanups, regarding aspects such as board name, code
and headers organization as well as deprecated and missing config options.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>

There are a number of AMCC platforms which are close to, or with some
toolchains exceeding, the size constraints.  Disable CONFIG_SYS_LONGHELP
to get us room to build with again.

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

Copy these from Linux v4.5-rc6 tag.

This is needed so that we can keep up with newer gcc versions.  Note
that we don't have the uapi/ hierarchy from the kernel so continue to
use <linux/types.h>

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