Many AHCI controllers are identical, the main (and often the
only) difference being the PCI Vendor ID/Device ID combination
reported by the device.

This change allows the config file to define a list of PCI vendor
ID/device ID pairs. The driver would scan the list and initialize
the first device it finds.

No actual multiple device list is introduced yet, this change
just add the framework.
Signed-off-by: NVadim Bendebury <vbendeb@chromium.org>
Signed-off-by: NTaylor Hutt <thutt@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

With an Intel AHCI controller, the driver does not operate properly
if the requested amount of blocks to read exceeds 255.

It is probably possible to specify 0 as the block count and the driver
will read 256 blocks, but it was decided to limit the number of blocks
read at once to 128 (it should be a power of 2 for the optimal
performance of solid state drives).
Signed-off-by: NVadim Bendebury <vbendeb@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>

This patch fixes the following compile warning:
zfs.c:2006:1: warning: 'zfs_label' defined but not used [-Wunused-function]
zfs.c:2029:1: warning: 'zfs_uuid' defined but not used [-Wunused-function]
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Jorgen Lundman <lundman@lundman.net>

This patch fixes the following compile warnings:

cmd_zfs.c:177:1: warning: initialization from incompatible pointer type [enabled by default]
cmd_zfs.c:177:1: warning: (near initialization for '_u_boot_list_cmd_zfsls.cmd') [enabled by default]
cmd_zfs.c:182:1: warning: initialization from incompatible pointer type [enabled by default]
cmd_zfs.c:182:1: warning: (near initialization for '_u_boot_list_cmd_zfsload.cmd') [enabled by default]
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Jorgen Lundman <lundman@lundman.net>

We add CONFIG_ENV_VARS_UBOOT_CONFIG,
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG and CONFIG_BOARD_LATE_INIT to set
the variables and then fdtfile and findfdt to make us of this.  It is
now possible to do 'run findfdt' to have fdtfile be set to the value of
the dtb file to load for the board we are running on.
Signed-off-by: NTom Rini <trini@ti.com>

CONFIG_ENV_VARS_UBOOT_CONFIG creates environment variables indicating
which configuration U-Boot was built for. Some U-Boot binaries run on
multiple boards, and hence this information may not uniquley describe
the HW that U-Boot is actually running on. Another patch introduces
environment variable board_name to represent that. In order to avoid
scripts having to check $board_name, use it if set, and then fall back
to using $board, make CONFIG_ENV_VARS_UBOOT_CONFIG also set a default
value for board_name, so that variable is always available.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

This option is intended to be set by boards which will set the
board_name and board_rev environment variables.  These are to be used
when the U-Boot binary can support more than one board type at run-time
and the user needs an easy way (for example for scripting to determine
what device tree to load) to determine what board they are on.
Signed-off-by: NTom Rini <trini@ti.com>

Grame is still listed since he has agreed to continue with some review.
Also add an alias to shorten things.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The %p format of printf() would print a pointer to address null as
"(null)".  This makes sense in a real OS where a NULL pointer must
never be dereferenced, but this is a bootloader, and there are cases
where accessing the data at address null makes perfect sense.

Remove the special case in lib/vsprintf.c using "#if 0" with a comment
to make clear this was an intentional change and to stop re-adding
this code.
Signed-off-by: NWolfgang Denk <wd@denx.de>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

When putting pointers into a format string use %p to ensure that they
are printed correctly regardless of bitsize.  This fixes warnings on
sandbox on 64bit systems.

Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Gerald Van Baren <vanbaren@cideas.com>
Signed-off-by: NTom Rini <trini@ti.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Without this, fstypes[].probe points at the wrong place, so calling the
function results in undefined behaviour.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NAndreas Bießmann <andreas.devel@googlemail.com>

When BUILD_NBUILDS is > 1 we run the tidy command.  With the addition of
DocBook this now includes a -C doc/DocBook and a 'entering/leaving' pair
of messages happen.  Since we don't want to see what's being cleaned
here, we can just invoke make -s like we do when building.
Signed-off-by: NTom Rini <trini@ti.com>

Fix the following error in the ext4 command:

cmd_ext4.c:110:3: error: format '%lu' expects argument of type
'long unsigned int', but argument 4 has type 'int' [-Werror=format]
Signed-off-by: NSimon Glass <sjg@chromium.org>

Deassert the CONFIG pin before asserting it again. This assures that the
FPGA will be resetted and therefore configuration will be correctly
enabled.

This is also already done on other FPGA's, e.g. Stratix.
Signed-off-by: NStephan Gatzka <stephan.gatzka@hbm.com>
Signed-off-by: NStefan Roese <sr@denx.de>

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: NStephen Warren <swarren@nvidia.com>

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: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>

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: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>
Acked-by: NSimon Glass <sjg@chromium.org>

This patch remove the env saving in NAND as so far the
NAND driver is not ported to the M54418TWR platform.
Signed-off-by: NJason Jin <Jason.jin@freescale.com>

The M54418TWR lds file  need to update since commit:

8b493a52

common: Discard the __u_boot_cmd section

The command declaration now uses the new LG-array method to generate
list of commands. Thus the __u_boot_cmd section is now superseded and
redundant and therefore can be removed. Also, remove externed symbols
associated with this section from include/command.h .
Signed-off-by: NJason Jin <Jason.jin@freescale.com>

Once more, some of the previous changes caused the code to grow, which
causes errors like

u-boot.lds:74 cannot move location counter backwards (from 40008384 to 40008000)

when building with some older tool chains (like ELDK 4.2).
Adjust the linker script to make fit again.
Signed-off-by: NWolfgang Denk <wd@denx.de>
Cc: Conn Clark <clark@esteem.com>

Once more, some of the previous changes caused the code to grow, which
causes errors like

u-boot.lds:80 cannot move location counter backwards (from 400082a4 to 40008000)

when building with some older tool chains (like ELDK 4.2).
Adjust the linker script to make fit again.
Signed-off-by: NWolfgang Denk <wd@denx.de>

These boards have long reached EOL, and there has been no indication
of any active users of such hardware for years.  Get rid of the dead
weight.
Signed-off-by: NWolfgang Denk <wd@denx.de>
Cc: Wolfgang Grandegger <wg@denx.de>

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: NStephen Warren <swarren@nvidia.com>
Acked-by: NAllen Martin <amartin@nvidia.com>
Acked-by: NSimon Glass <sjg@chromium.org>
Tested-by: NSimon Glass <sjg@chromium.org>

CONFIG_BAUDRATE and KS8695_UART_LINEC_WLEN8 used for UART registers

Added clock settings for MFC, FIMC, FB and G3D. They are clocked to
maximum respective frequencies as per datasheet.
Signed-off-by: NAnnamalai Lakshmanan <annamalai.lakshmanan@linaro.org>
Signed-off-by: NGiridhar Maruthy <giridhar.maruthy@linaro.org>
Signed-off-by: NInderpal Singh <inderpal.singh@linaro.org>
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>

SX1 does not build properly by itself, is not built
as part of MAKEALL arm or MAKEALL -a arm, and is only
present in Makefile, not boards.cfg. As it also has no
entry in MAINTAINERS, it is orphan and non-functional.
Remove it.
Signed-off-by: NAlbert ARIBAUD <albert.u.boot@aribaud.net>

This is a dead code, remove it.
Signed-off-by: NMarek Vasut <marex@denx.de>

Clean up away old macros and such, so the file doesn't start piling
up cruft.
Signed-off-by: NMarek Vasut <marex@denx.de>

clean

This driver is no longer used, remove it.
Signed-off-by: NMarek Vasut <marex@denx.de>

This stuff has been rotting in the tree for a while now. Remove it.
Signed-off-by: NMarek Vasut <marex@denx.de>

This stuff has been rotting in the tree for a year now. Remove it.
Signed-off-by: NMarek Vasut <marex@denx.de>

This stuff has been rotting in the tree for a year now. Remove it.
Signed-off-by: NMarek Vasut <marex@denx.de>

Remove calls to serial_assign() that are failing now that it returns a
proper error code.  This calls were not actually doing anything
because they passed the name of a stdio_dev when a serial_device name
is exptectd.
Signed-off-by: NAllen Martin <amartin@nvidia.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>
Acked-by: NMarek Vasut <marex@denx.de>
Acked-by: NSimon Glass <sjg@chromium.org>
Tested-by: NSimon Glass <sjg@chromium.org>
Tested-by: NStephen Warren <swarren@nvidia.com>

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: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>

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: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>

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: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>