cosmetic: suvd3: align #defines

Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
cleanup: use CONFIG_QE instead of CONFIG_MPC8360 || CONFIG_MPC832x

simplify #if defined(CONFIG_MPC8360) || defined(CONFIG_MPC832x)
for qe variables
with #if defined(CONFIG_QE)

Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
cleanup: introduce CONFIG_MPC830x

Introduce a new configuration token CONFIG_MPC830x to be shared among
mpc8308 and mpc8309. Define it for existing 8308 boards, and refactor
existing common code so to make future introduction of 8309 simpler.

Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
mpc83xx: add support for mpc8309

This processor, though very similar to other members of the
PowerQUICC II Pro family (namely 8308, 8360 and 832x), provides
yet another feature set than any supported sibling.

Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
km83xx: add common support for km8309 boards

Add support for Keymile boards based on mpc8309
(it would be only kmvect1 for now)

Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
[#elseif -> #if to allow kmcoge5ne and kmeter1 to build successfully]
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
km83xx: add kmvect1 board

Add support for the new kmvect1 board powered by the mpc8309 processor.
As this board is very similar to the existing suvd3, instead of adding a
new config header file, just add a new config option to suvd3.h

Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
ColdFire: Fix unused variable in cpu_init.c

Fix the following build warnings in cpu_init.c:

cpu_init.c: In function 'cpu_init_f':
cpu_init.c:47:9: warning: unused variable 'pll'
cpu_init.c:46:10: warning: unused variable 'fbcs'
cpu_init.c:44:10: warning: unused variable 'scm1'

Signed-off-by: Alison Wang <b18965@freescale.com>
ColdFire: Add MCF5441x CPU support

Add MCF5441x CPU support.

The MCF5441x devices are a family of highly-integrated 32-bit
microprocessors based on the Version 4m ColdFire microarchitecture,
comprising of the V4 integer core, memory management unit(MMU) and
enchanced multiply-accumulate unit(EMAC).

Signed-off-by: TsiChung Liew <tsicliew@gmail.com>
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
Signed-off-by: Alison Wang <b18965@freescale.com>
ColdFire: Add Freescale MCF54418TWR ColdFire development board support

Add Freescale MCF54418TWR ColdFire development board support.

Signed-off-by: TsiChung Liew <tsicliew@gmail.com>
Signed-off-by: Jason Jin <Jason.jin@freescale.com>
Signed-off-by: Alison Wang <b18965@freescale.com>
drivers/i2c/fsl_i2c.c: sparse fix

fsl_i2c.c:217:14: warning: symbol 'get_i2c_clock' was not declared. Should it be static?

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Acked-by: Heiko Schocher <hs@denx.de>
drivers/serial/serial_ns16550.c: sparse fixes

serial_ns16550.c:222:1: warning: symbol 'eserial1_init' was not declared. Should it be static?
serial_ns16550.c:222:1: warning: symbol 'eserial1_setbrg' was not declared. Should it be static?
serial_ns16550.c:222:1: warning: symbol 'eserial1_getc' was not declared. Should it be static?
serial_ns16550.c:222:1: warning: symbol 'eserial1_tstc' was not declared. Should it be static?
serial_ns16550.c:222:1: warning: symbol 'eserial1_putc' was not declared. Should it be static?
serial_ns16550.c:222:1: warning: symbol 'eserial1_puts' was not declared. Should it be static?
serial_ns16550.c:225:1: warning: symbol 'eserial2_init' was not declared. Should it be static?
serial_ns16550.c:225:1: warning: symbol 'eserial2_setbrg' was not declared. Should it be static?
serial_ns16550.c:225:1: warning: symbol 'eserial2_getc' was not declared. Should it be static?
serial_ns16550.c:225:1: warning: symbol 'eserial2_tstc' was not declared. Should it be static?
serial_ns16550.c:225:1: warning: symbol 'eserial2_putc' was not declared. Should it be static?
serial_ns16550.c:225:1: warning: symbol 'eserial2_puts' was not declared. Should it be static?
serial_ns16550.c:228:1: warning: symbol 'eserial3_init' was not declared. Should it be static?
serial_ns16550.c:228:1: warning: symbol 'eserial3_setbrg' was not declared. Should it be static?
serial_ns16550.c:228:1: warning: symbol 'eserial3_getc' was not declared. Should it be static?
serial_ns16550.c:228:1: warning: symbol 'eserial3_tstc' was not declared. Should it be static?
serial_ns16550.c:228:1: warning: symbol 'eserial3_putc' was not declared. Should it be static?
serial_ns16550.c:228:1: warning: symbol 'eserial3_puts' was not declared. Should it be static?
serial_ns16550.c:231:1: warning: symbol 'eserial4_init' was not declared. Should it be static?
serial_ns16550.c:231:1: warning: symbol 'eserial4_setbrg' was not declared. Should it be static?
serial_ns16550.c:231:1: warning: symbol 'eserial4_getc' was not declared. Should it be static?
serial_ns16550.c:231:1: warning: symbol 'eserial4_tstc' was not declared. Should it be static?
serial_ns16550.c:231:1: warning: symbol 'eserial4_putc' was not declared. Should it be static?
serial_ns16550.c:231:1: warning: symbol 'eserial4_puts' was not declared. Should it be static?

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
FAT: remove cur_part_nr

A future patch will implement the more standard filesystem API
fat_set_blk_dev(). This API has no way to know which partition number
the partition represents. Equally, future DM rework will make the
concept of partition number harder to pass around.

So, simply remove cur_part_nr from fat.c; its only use is in a
diagnostic printf, and the context where it's printed should make it
obvious which partition is referred to anyway (since the partition ID
would come from the user command-line that caused it).

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
FAT: initialize all fields in cur_part_info, simplify init

cur_part_info.{name,type} are strings. So, we don't need to memset()
the entire thing, just put the NULL-termination in the first byte.

Add missing initialization of the bootable and uuid fields.

None of these fields are actually used by fat.c. However, since it
stores the entire disk_partition_t, we should make sure that all fields
are valid.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
FAT: implement fat_set_blk_dev(), convert cmd_fat.c

This makes the FAT filesystem API more consistent with other block-based
filesystems. If in the future standard multi-filesystem commands such as
"ls" or "load" are implemented, having FAT work the same way as other
filesystems will be necessary.

Convert cmd_fat.c to the new API, so the code looks more like other files
implementing the same commands for other filesystems.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
APPLIED (tegra/next): ARM: tegra: define CONFIG_SYS_BOOTMAPSZ

This define indicates the size of the memory region where it is safe
to place data passed to the Linux kernel (ATAGs, DTB, initrd). The
value needs to be:

a) Less than or equal to RAM size.
b) Small enough that the area is not within the kernel's highmem region,
   since the kernel cannot access ATAGs/DTB/initrd from highmem.
c) Large enough to hold the kernel+DTB+initrd.

256M seems large enough for (c) in most circumstances, and small enough
to satisfy (a) and (b) across any possible Tegra board. Note that the
user can override this value via environment variable "bootm_mapsize"
if needed.

The advantage of defining BOOTMAPSZ is that we no longer need to define
variable fdt_high in the default environment. Previously, we defined
this to prevent the DTB from being relocated to the very end of RAM,
which on most Tegra systems is within highmem, and hence which would
cause boot failures. A user can still define this variable themselves
if they want the FDT to be either left in-place wherever loaded, or
copied to some other specific location. Similarly, there should no
longer be a strict requirement for the user to define initrd_high if
using an initrd.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED (tegra/next): ARM: tegra: use standard variables to define load addresses

Currently, Tegra's default environment uses non-standard variables to define
where boot scripts should load the kernel, FDT, and initrd. This change both
changes the variable names to match those described in U-Boot's README, and
shuffles their values around a little so that the values make a little more
sense; see comments in the patch for rationale behind the values chosen.

Note that this patch does remove the old non-standard variable "fdt_load" from
the default environment, so this patch requires people to change their boot
scripts.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
APPLIED (tegra/next): ARM: tegra: Harmony: enable ULPI USB port

The ULPI port is routed onto pins on the mini PCI Express connector. A
standard breakout board may be used to access the port.

* Add required DT entries to configure the ULPI port.
* Setup up the ULPI pinmux in the board code.
* Enable multiple USB controller and ULPI support in the board config.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED (tegra/next): ARM: tegra: Seaboard: enable multiple USB ports

The device tree already contains the required configuration for both the
USB1 and USB3 ports. Enable the required configuration options to enable
both these ports, which in turn allows the USB1 port to be used.

Note that on a true Seaboard, this port is typically used as a device
port hosting Tegra's USB recovery protocol. However, on the Springbank
derivative, this port is the only external USB port, so we enable it as
a host port so that USB peripherals may be used. Enabling this port in
U-Boot as a host port doesn't prevent the port from reverting to a
device port when the CPU is reset into recovery mode.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
APPLIED (tegra/next): ARM: tegra: Whistler: remove unused USB alias

Port USB1 on Whistler is intended as a device port for USB recovery.
Whistler's DT currently contains an alias for this USB port, even though
Whistler's config doesn't enable multiple USB controllers, so the alias
is unused. Remove the unused alias for consistency for now. Similar,
explicitly disable the port in the device tree too.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: fix u-boot.lds for -ffunction-sections/-fdata-sections

When -ffunction-sections or -fdata-section are used, symbols are placed
into sections such as .data.eserial1_device and .bss.serial_current.
Update the linker script to explicitly include these. Without this
change (at least with my gcc-4.5.3 built using crosstool-ng), I see that
the sections do end up being included, but __bss_end__ gets set to the
same value as __bss_start.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Allen Martin <amartin@nvidia.com>
Tested-by: Allen Martin <amartin@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
---
v3: No change.
v2: Removed changes from some entries where it wasn't needed.