ARM: enhance u-boot.lds to detect over-sized SPL

Add an ASSERT() to u-boot.lds to detect an SPL that doesn't fit within
SPL_TEXT_BASE..SPL_MAX_SIZE.

Different .lds files implement this check in two possible ways:
1) An ASSERT() like this
2) Defining a MEMORY region of size SPL_MAX_SIZE, and re-directing all
   linker output into that region. Since u-boot.lds is used for both
   SPL and main U-Boot, this would entail only sometimes defining a
   MEMORY region, and only sometimes performing that redirection, and
   hence option (1) was deemed much simpler, and hence implemented.

Note that this causes build failures at least for NVIDIA Tegra Seaboard
and Ventana. However, these are legitimate; the SPL doesn't fit within
the required space, and this does cause runtime issues.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Allen Martin <amartin@nvidia.com>
Tested-by: Allen Martin <amartin@nvidia.com>
Acked-by: Tom Rini <trini@ti.com>
---
v3: No change.
v2: New patch; replaced checks in Makefile.
ARM: tegra: derive CONFIG_SPL_MAX_SIZE instead of hard-coding it

For Tegra, the SPL and main U-Boot are concatenated together to form a
single memory image. Hence, the maximum SPL size is the different in
TEXT_BASE for SPL and main U-Boot. Instead of manually calculating
SPL_MAX_SIZE based on those two TEXT_BASE, which can lead to errors if
one TEXT_BASE is changed without updating SPL_MAX_SIZE, simply perform
the calculation automatically.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Allen Martin <amartin@nvidia.com>
Tested-by: Allen Martin <amartin@nvidia.com>
---
v3: No change.
v2: New patch.
ARM: tegra: select between Seaboard/Ventana at compile time

Seaboard and Ventana are very similar boards, and so share the seaboard.c
board file. The one difference needed so far is detected at run-time by
calling machine_is_ventana(). This bloats the Ventana build with code
that is never used. Switch to detecting Ventana at compile time to remove
bloat. This shaves ~5K off the SPL size on Ventana, and makes the SPL fit
within the max size.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Allen Martin <amartin@nvidia.com>
Tested-by: Allen Martin <amartin@nvidia.com>
---
v3: Combined back-to-back #ifdefs.
v2: New patch to replace modification of CONFIG_SYS_TEXT_BASE.
ARM: tegra: don't request GPIO from Seaboard's SPL

Seaboard has a GPIO that switches an external mux between Tegra's debug
UART and SPI flash. This is initialized from the SPL so that SPL debug
output can be seen. Simplify the code that does this, and don't actually
request the GPIO in the SPL; just program it. This saves ~4.5K from the
size of the SPL, mostly BSS due to the large gpio_names[] table that is
no longer required. This makes Seaboard's SPL fit within the current max
size.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Allen Martin <amartin@nvidia.com>
Tested-by: Allen Martin <amartin@nvidia.com>
---
v3: No change.
v2: New patch to replace modification of CONFIG_SYS_TEXT_BASE.
SPL: make jump_to_image_no_args a weak symbol

Change jump_to_image_no_args() to a weak symbol to allow override by
SoC specific code.  This is required by tegra because the SPL runs on
a different CPU from the image it is loading, so tegra specific
initialization is required to start the host CPU.  Pass in spl_image
as a parameter for the same reason.

Signed-off-by: Allen Martin <amartin@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
tegra: move to common SPL framework

Change tegra SPL to use common SPL framework.  Any tegra specific
initialization is now done in spl_board_init() instead of
board_init_f()/board_init_r().  Only one SPL boot target is supported
on tegra, which is boot to RAM image.  jump_to_image_no_args() must be
overridden on tegra so the host CPU can be initialized.

Signed-off-by: Allen Martin <amartin@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
tegra20: initialize variable to avoid compiler warning

Initialize this variable to avoid a compiler warning about possible
use of uninitialized variable with gcc 4.4.6.

Signed-off-by: Allen Martin <amartin@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
HACK: fix return value of serial_assign to get printfs working again

This reverts a recent change to serial_assign() that broke printfs on
tegra.  I don't think this is the real fix, but I'm just putting this
out for others who want to test tegra patches for the other
regressions.

Signed-off-by: Allen Martin <amartin@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: TrimSlice: add support for USB1 port

FIXME: This doesn't work; check Compulab's downstream U-Boot for the
startup timing workaround they have...

TrimSlice's USB1 port has two purposes; it either acts as a device port
hosting Tegra's USB recovery protocol, or acts as a host port connected
to the internal USB->SATA bridge chip, which may in turn be connected to
an SSD or HDD. Add the appropriate device tree and board configuration
options to enable this port as a host port, and route the port to the
SATA bridge using the VBUS GPIO.

Signed-off-by: Stephen Warren <swarren@nvidia.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>
---
v4: New patch: Dropped addition of part number of disk_partition_t, and
replaced it with this patch.
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>
---
v4: No change (just rebased).
v3: New patch.
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>
---
v4: No change (just rebased).
v3: Rebase on new fat.c cleanup patch.
v2: Fix inverted test of get_partition_info() result in fat_register_device().
fs: delete unused Makefile

fs/Makefile is unused. The top-level Makefile sets LIBS-y += fs/xxx and
hence causes make to directly descend two directory levels into each
individual filesystem, and it never descends into fs/ itself.

So, delete this useless file.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Acked-by: Simon Glass <sjg@chromium.org>
---
v4: No change.
v3: No change.
v2: No change.
fs: separate CONFIG_FS_{FAT,EXT4} from CONFIG_CMD_{FAT,EXT*}

This makes the FAT and ext4 filesystem implementations build if
CONFIG_FS_{FAT,EXT4} are defined, rather than basing the build on
whether CONFIG_CMD_{FAT,EXT*} are defined. This will allow the
filesystems to be built separately from the filesystem-specific commands
that use them. This paves the way for the creation of filesystem-generic
commands that used the filesystems, without requiring the filesystem-
specific commands.

Minor documentation changes are made for this change.

The new config options are automatically selected by the old config
options to retain backwards-compatibility.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
---
v4: No change.
v3: No change.
v2: New patch.
fs: add filesystem switch libary, implement ls and fsload commands

Implement "ls" and "fsload" commands that act like {fat,ext2}{ls,load},
and transparently handle either file-system. This scheme could easily be
extended to other filesystem types; I only didn't do it for zfs because
I don't have any filesystems of that type to test with.

Replace the implementation of {fat,ext[24]}{ls,load} with this new code
too.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v4:
* Use FS_TYPE_* everywhere, rather than separate FS_* and FS_TYPE_*.
* Make fs_set_blk_dev() loop over a table of filesystems.
v3:
* Updated the implementation of the new commands to be suitable for use
  as the body of {fat,ext[24]}{ls,load} too.
* Enhanced the implementation to make more fsload parameters optional
  (load address, filename); they can now come from environment variables
  like ext2load supported.
* Moved implementation into fs.c.
* Removed cmd_ext_common.c.
* s/partition/filesystem/ in patch subject.
v2:
* Build cmd_fs.c when CONFIG_CMD_FS_GENERIC not always.
* Use new CONFIG_FS_{FAT,EXT4} rather than CONFIG_CMD_{FAT,EXT2}.
* Implemented fs_close() and call it from the tail of fs_ls() and fs_read().
  This ensures that any other usage of e.g. the ext4 library between fs_*()
  calls, then the two usages won't interfere.
* Re-organized fs.c to reduce the number of ifdef blocks.
* Added argc checking to do_ls().
tegra: use generic fs commands in BOOTCOMMAND

Modify tegra-common-post.h's BOOTCOMMAND definition to use the generic
filesystem command fsload rather than separate fatload and ext2load.
This removes the need to iterate over supported filesystem types in the
boot command.

This requires editing all board config headers to enable the new
commands. The now-unused commands are left enabled to assue backwards
compatibility with any user scripts. Boards (all from Avionic Design)
which define custom BOOTCOMMAND values are not affected.

Signed-off-by: Stephen Warren <swarren@nvidia.com>