fdt: fix dts preprocessor options

Using "-ansi" preprocessor option will cause dts lines that begin with
'#' to choke the preprocessor.  Change to "-x assembler-with-cpp"
instead which is what the kernel uses to preprocess dts files.

Signed-off-by: Allen Martin <amartin@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
treewide: include libfdt_env.h before fdt.h

and, if including libfdt.h which includes libfdt_env.h in
the correct order, don't include fdt.h before libfdt.h.

this is needed to get the fdt type definitions set from
the project environment before fdt.h uses them.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Cc: Jerry Van Baren <gvb.uboot@gmail.com>
libfdt_env.h: add fdt type definitions

fdt types are big endian.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Cc: Jerry Van Baren <gvb.uboot@gmail.com>
libfdt: update fdt.h from upstream dtc

upstream dtc commit feafcd972cb744750a65728440c99526e6199a6d
"dtc/libfdt: introduce fdt types for annotation by endian checkers".

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Cc: Jerry Van Baren <gvb.uboot@gmail.com>
libfdt: update from upstream dtc commit 142419e

commit 142419e "dtc/libfdt: sparse fixes", for u-boot's libfdt copy.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Cc: Jerry Van Baren <gvb.uboot@gmail.com>
common/fdt_support.c: sparse fixes

trivial:

fdt_support.c:89:64: warning: Using plain integer as NULL pointer
fdt_support.c:325:65: warning: Using plain integer as NULL pointer
fdt_support.c:352:65: warning: Using plain integer as NULL pointer

For the following bad constant expression, We hardcode the max. number of
memory banks to four for the foreseeable future, and add an error with
instructions on what to do once it's exceeded:

fdt_support.c:397:22: error: bad constant expression

For the rest below, sparse found a couple of wrong endian conversions
in of_bus_default_translate() and fdt_get_base_address(), but
otherwise the rest is mostly annotation fixes:

fdt_support.c:64:24: warning: cast to restricted __be32
fdt_support.c:192:21: warning: incorrect type in assignment (different base types)
fdt_support.c:192:21:    expected unsigned int [unsigned] [usertype] tmp
fdt_support.c:192:21:    got restricted __be32 [usertype] <noident>
fdt_support.c:201:21: warning: incorrect type in assignment (different base types)
fdt_support.c:201:21:    expected unsigned int [unsigned] [addressable] [usertype] tmp
fdt_support.c:201:21:    got restricted __be32 [usertype] <noident>
fdt_support.c:304:13: warning: incorrect type in assignment (different base types)
fdt_support.c:304:13:    expected unsigned int [unsigned] [usertype] val
fdt_support.c:304:13:    got restricted __be32 [usertype] <noident>
fdt_support.c:333:13: warning: incorrect type in assignment (different base types)
fdt_support.c:333:13:    expected unsigned int [unsigned] [usertype] val
fdt_support.c:333:13:    got restricted __be32 [usertype] <noident>
fdt_support.c:359:13: warning: incorrect type in assignment (different base types)
fdt_support.c:359:13:    expected unsigned int [unsigned] [usertype] val
fdt_support.c:359:13:    got restricted __be32 [usertype] <noident>
fdt_support.c:373:21: warning: cast to restricted __be32
fdt_support.c:963:48: warning: incorrect type in argument 1 (different base types)
fdt_support.c:963:48:    expected restricted __be32 const [usertype] *p
fdt_support.c:963:48:    got unsigned int [usertype] *<noident>
fdt_support.c:971:48: warning: incorrect type in argument 1 (different base types)
fdt_support.c:971:48:    expected restricted __be32 const [usertype] *p
fdt_support.c:971:48:    got unsigned int [usertype] *<noident>
fdt_support.c:984:29: warning: incorrect type in argument 1 (different base types)
fdt_support.c:984:29:    expected restricted __be32 const [usertype] *cell
fdt_support.c:984:29:    got unsigned int [usertype] *addr
fdt_support.c:996:32: warning: incorrect type in argument 1 (different base types)
fdt_support.c:996:32:    expected restricted __be32 const [usertype] *cell
fdt_support.c:996:32:    got unsigned int [usertype] *addr
fdt_support.c:1041:41: warning: incorrect type in argument 1 (different base types)
fdt_support.c:1041:41:    expected restricted __be32 const [usertype] *cell
fdt_support.c:1041:41:    got unsigned int [usertype] *addr
fdt_support.c:1053:41: warning: incorrect type in argument 2 (different base types)
fdt_support.c:1053:41:    expected restricted __be32 const [usertype] *range
fdt_support.c:1053:41:    got unsigned int const [usertype] *[assigned] ranges
fdt_support.c:1064:53: warning: incorrect type in argument 2 (different base types)
fdt_support.c:1064:53:    expected restricted __be32 const [usertype] *addr
fdt_support.c:1064:53:    got unsigned int [usertype] *addr
fdt_support.c:1110:50: warning: incorrect type in argument 2 (different base types)
fdt_support.c:1110:50:    expected restricted __be32 const [usertype] *addr
fdt_support.c:1110:50:    got unsigned int *<noident>
fdt_support.c:1121:49: warning: incorrect type in argument 1 (different base types)
fdt_support.c:1121:49:    expected restricted __be32 const [usertype] *cell
fdt_support.c:1121:49:    got unsigned int *<noident>
fdt_support.c:1147:60: warning: incorrect type in argument 2 (different base types)
fdt_support.c:1147:60:    expected restricted __be32 const [usertype] *addr
fdt_support.c:1147:60:    got unsigned int *<noident>
fdt_support.c:1081:5: warning: symbol '__of_translate_address' was not declared. Should it be static?
fdt_support.c:1154:5: error: symbol 'fdt_translate_address' redeclared with different type (originally declared at include/fdt_support.h:95) - incompatible argument 3 (different base types)
fdt_support.c: In function 'fdt_node_offset_by_compat_reg':
fdt_support.c:1173:17: warning: initialization discards 'const' qualifier from pointer target type [enabled by default]

See also linux kernel commit 0131d897 "of/address: use proper
endianess in get_flags".

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Cc: Jerry Van Baren <gvb.uboot@gmail.com>
Clean up libfdt.h includes

The libfdt.h file is the definition file for libfdt.  It is unnecessary
to include other fdt header files (the necessary ones are pulled in
by libfdt.h).

Signed-off-by: Gerald Van Baren <gvb@unssw.com>
Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Stefan Roese <sr@denx.de>
OMAP3: use a single board file for IGEP devices

Even when the IGEPv2 board and the IGEP Computer-on-Module
are different from a form factor point of view, they are
very similar in the fact that share many components and how
they are wired.

So, it is possible (and better) to have a single board file
for both devices and just use the CONFIG_MACH_TYPE to make
a differentiation between each board when needed.

This change avoids code duplication by removing 298 lines of
code and makes future maintenance easier.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
OMAP3: igep00x0: add boot status GPIO LED

This patch adds an GPIO LED boot status for IGEP boards.

The GPIO LED used is the red LED0 while the Linux kernel
uses the green LED0 as the boot status.

By using different GPIO LEDs, the user can know in which
step of the boot process the board currently is.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
OMAP3: igep00x0: use official board names.

This trivial patch only changes current boards names for the official
names.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
OMAP3: igep00x0: add missing include mach-types.h in config.

Current '#if' directives (used in igep00x0.h config file) comparing MACH_TYPE
values in igep00x0.h doesn't work as expected. The comparision between
CONFIG_MACH_TYPE and MACH_TYPE_IGEP0020 is always true independent of the IGEP
machine configured.

For example, following directive

 if (CONFIG_MACH_TYPE == MACH_TYPE_IGEP0020)
    define something
 endif

Is always evaluated true although we configure u-boot for MACH_TYPE_IGEP0030.

The build doesn't shows any error so looks that both defines had always the same
value. Including the mach-types.h file sets properly the value of
MACH_TYPE_IGEPxxxx.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
OMAP3: igep00x0: Add new IGEP COM PROTON.

The IGEP COM PROTON is a new ultra compact module design with an
on-board ethernet controller.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
SPL: ONENAND: Fix some ONENAND related defines.

Some ONENAND related defines use the term ONE_NAND instead of
ONENAND, as the technology name is ONENAND this patch replaces
all these defines.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
SPL: ONENAND: Fix onenand_spl_load_image implementation.

Tested with an IGEPv2 board seems that current onenand_spl_load_image implementation
doesn't work. This patch fixes this function changing the read loop and reading the
onenand blocks from page to page.

Tested with various IGEP based boards with a OneNAND from Numonyx.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
SPL: ONENAND: Support SPL to boot u-boot from OneNAND.

This patch will allow use SPL to boot an u-boot from the OneNAND.

Tested with IGEPv2 board with a OneNAND from Numonyx

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
OMAP3: Initialize gpmc if SPL_ONENAND_SUPPORT is enabled.

In order to use SPL boot from OneNAND we should initialize the gpmc.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>