In the structure returned by the ATA identify device command, there are two
fields which describe the device capacity. One is a 32 bit data type which
reports the number of sectors as a 28 bit LBA, and the other is a 64 bit data
type which is for a 48 bit LBA. If the device doesn't support 48 bit LBAs,
the small value is the only value with the correct size. If it supports more,
if the number of sectors is small enough to fit into 28 bits, both fields
reflect the correct value. If it's too large, the smaller field has 28 bits of
1s, 0xfffffff, and the other field has the correct value.

The AHCI driver is implemented by attaching to the generic SCSI code and
translating on the fly between SCSI binary data structures and AHCI data
structures. It responds to requests to execute specific SCSI commands by
executing the equivalent AHCI commands and then crafting a response which
matches what a SCSI disk would send.

The AHCI driver now considers both fields and chooses the correct one when
implementing both the SCSI READ CAPACITY (10) and READ CAPACITY (16) commands.

Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

- print the correct speed
- print all the AHCI capability flags
(information taken from Linux kernel driver)
- clean up some comments

For example, this might show the following string:
AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3 impl SATA mode

Signed-off-by: Stefan Reinauer <reinauer@chromium.org>

Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>

Add a new function to find out the number of available SCSI disks. Also
set the 'scsidevs' environment variable after each scan.

Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

This includes were outside an #ifdef CONFIG_PPC, but there is not reason
to exclude powerpc from using them.

Move the declaration outside the #ifdef.

Signed-off-by: Simon Glass <sjg@chromium.org>

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: Tom 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: Stephen Warren <swarren@nvidia.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

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>

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>

This patch remove the env saving in NAND as so far the
NAND driver is not ported to the M54418TWR platform.

Signed-off-by: Jason Jin <Jason.jin@freescale.com>

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: Wolfgang Denk <wd@denx.de>
Cc: Wolfgang Grandegger <wg@denx.de>

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: Albert ARIBAUD <albert.u.boot@aribaud.net>

This driver is no longer used, remove it.

Signed-off-by: Marek Vasut <marex@denx.de>

This stuff has been rotting in the tree for a year now. Remove it.

Signed-off-by: Marek Vasut <marex@denx.de>

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>

Add the required config.mk logic for this SoC as well as the BOOT_DEVICE
define.  Finally, enable the options on the am335x_evm.

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

Add video support to the board with the display
focaltech etm070003dh6.

Signed-off-by: Stefano Babic <sbabic@denx.de>

Some GPIOs differ in the new revision board.
Previous revision are considered obsolete and
they will not anymore supported.

Signed-off-by: Stefano Babic <sbabic@denx.de>

The mcx board was slightly modified and the pinmux must be updated.
There is no need to support the old board, that becomes obsolete.

Signed-off-by: Stefano Babic <sbabic@denx.de>

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>

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>

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>

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>

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>

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

Neither cm-t35, nor cm-t3730 is using OneNAND or flash.
Remove the related defines from config file.

Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>

Fix usage of 'mmc rescan' by many configs.  Proper use is
'mmc dev ${mmcdev}; mmc rescan' to set the mmc device and then rescan
the device.  'mmc rescan' itself does not take any arguments.

Signed-off-by: Andrew Bradford <andrew@bradfordembedded.com>

LAN8720 PHY is used on Freescale C2X0QDS board.

Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>

Starting from QMan3.0, the QMan clock cycle needs be exposed so that the kernel
driver can use it to calculate the shaper prescaler and rate.

Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>

The T4240QDS is a high-performance computing evaluation, development and
test platform supporting the T4240 QorIQ Power Architecture™ processor.

SERDES Connections
  32 lanes grouped into four 8-lane banks
  Two “front side” banks dedicated to Ethernet
  Two “back side” banks dedicated to other protocols
DDR Controllers
  Three independant 64-bit DDR3 controllers
  Supports rates up to 2133 MHz data-rate
  Supports two DDR3/DDR3LP UDIMM/RDIMMs per controller
QIXIS System Logic FPGA

Each DDR controller has two DIMM slots. The first slot of each controller
has up to 4 chip selects to support single-, dual- and quad-rank DIMMs.
The second slot has only 2 chip selects to support single- and dual-rank
DIMMs. At any given time, up to total 4 chip selects can be used.

Detail information can be found in doc/README.t4qds

Signed-off-by: York Sun <yorksun@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>

The multirate ethernet media access controller (mEMAC) interfaces to
10Gbps and below Ethernet/IEEE 802.3 networks via either RGMII/RMII
interfaces or XAUI/XFI/SGMII/QSGMII using the high-speed SerDes interface.

Signed-off-by: Sandeep Singh <Sandeep@freescale.com>
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>

Add support for Freescale T4240 SoC. Feature of T4240 are
(incomplete list):

12 dual-threaded e6500 cores built on Power Architecture® technology
  Arranged as clusters of four cores sharing a 2 MB L2 cache.
  Up to 1.8 GHz at 1.0 V with 64-bit ISA support (Power Architecture
    v2.06-compliant)
  Three levels of instruction: user, supervisor, and hypervisor
1.5 MB CoreNet Platform Cache (CPC)
Hierarchical interconnect fabric
  CoreNet fabric supporting coherent and non-coherent transactions with
    prioritization and bandwidth allocation amongst CoreNet end-points
  1.6 Tbps coherent read bandwidth
  Queue Manager (QMan) fabric supporting packet-level queue management and
    quality of service scheduling
Three 64-bit DDR3/3L SDRAM memory controllers with ECC and interleaving
    support
  Memory prefetch engine (PMan)
Data Path Acceleration Architecture (DPAA) incorporating acceleration for
    the following functions:
  Packet parsing, classification, and distribution (Frame Manager 1.1)
  Queue management for scheduling, packet sequencing, and congestion
    management (Queue Manager 1.1)
  Hardware buffer management for buffer allocation and de-allocation
    (BMan 1.1)
  Cryptography acceleration (SEC 5.0) at up to 40 Gbps
  RegEx Pattern Matching Acceleration (PME 2.1) at up to 10 Gbps
  Decompression/Compression Acceleration (DCE 1.0) at up to 20 Gbps
  DPAA chip-to-chip interconnect via RapidIO Message Manager (RMAN 1.0)
32 SerDes lanes at up to 10.3125 GHz
Ethernet interfaces
  Up to four 10 Gbps Ethernet MACs
  Up to sixteen 1 Gbps Ethernet MACs
  Maximum configuration of 4 x 10 GE + 8 x 1 GE
High-speed peripheral interfaces
  Four PCI Express 2.0/3.0 controllers
  Two Serial RapidIO 2.0 controllers/ports running at up to 5 GHz with
    Type 11 messaging and Type 9 data streaming support
  Interlaken look-aside interface for serial TCAM connection
Additional peripheral interfaces
  Two serial ATA (SATA 2.0) controllers
  Two high-speed USB 2.0 controllers with integrated PHY
  Enhanced secure digital host controller (SD/MMC/eMMC)
  Enhanced serial peripheral interface (eSPI)
  Four I2C controllers
  Four 2-pin or two 4-pin UARTs
  Integrated Flash controller supporting NAND and NOR flash
Two eight-channel DMA engines
Support for hardware virtualization and partitioning enforcement
QorIQ Platform's Trust Architecture 1.1

Signed-off-by: York Sun <yorksun@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>

The P5040 does not have SRIO, so don't put the SRIO definitions in
corenet_ds.h.  They belong in the board-specific header files.

Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>

Enable Coreboot and EXT4 Filesystems on the coreboot board.

Signed-off-by: Simon Glass <sjg@chromium.org>

This change adds CBFS support and some commands to use it to u-boot. These
commands are:

cbfsinit - Initialize CBFS support and pull all metadata into RAM. The end of
the ROM is an optional parameter which defaults to the standard 0xffffffff and
can be used to support multiple CBFSes in a system. The last one set up with
cbfsinit is the one that will be used.

cbfsinfo - Print information from the CBFS header.

cbfsls - Print out the size, type, and name of all the files in the current
CBFS. Recognized types are translated into symbolic names.

cbfsload - Load a file from CBFS into memory. Like the similar command for fat
filesystems, you can optionally provide a maximum size.

Support for CBFS is compiled in when the CONFIG_CMD_CBFS option is specified.

The CBFS driver can also be used programmatically from within u-boot.

If u-boot needs something out of CBFS very early before the heap is
configured, it won't be able to use the normal CBFS support which caches some
information in memory it allocates from the heap. The
cbfs_file_find_uncached function searches a CBFS instance without touching
the heap.

Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

The size of an LBA type changes depending on this option. We need to
use a different printf() string in each case, so create a define for
this.

Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

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: Marek Vasut <marex@denx.de>
Cc: Joe Hershberger <joe.hershberger@gmail.com>
Cc: Mike Frysinger <vapier@gentoo.org>

This patch converts the old method of creating a list of command
onto the new LG-arrays code. The old u_boot_cmd section is converted
to new u_boot_list_cmd subsection and LG-array macros used as needed.

Minor adjustments had to be made to the common code to work with the
LG-array macros, mostly the fixup_cmdtable() calls are now passed the
ll_entry_start and ll_entry_count instead of linker-generated symbols.

The command.c had to be adjusted as well so it would use the newly
introduced LG-array API instead of directly using linker-generated
symbols.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Joe Hershberger <joe.hershberger@gmail.com>
Cc: Mike Frysinger <vapier@gentoo.org>

This patch adds support for linker-generated array. These arrays
are a generalization of the U-Boot command declaration approach.

Basically, the idea is to generate an array, where elements of the
array are statically initialized at compile time and each element
is declared separatelly at different place. Such array is assembled
together into continuous piece of memory by linker and a pointer to
it's first entry can then be retrieved via accessor.

The actual implementation relies on placing any variable that is to
represent an element of LG-array into particular subsection of the
.u_boot_list linker section . The subsection is determined by user
options. Once compiled, it is possible to dump all symbols placed
in .u_boot_list section and the subsections in which they should be
and generate appropriate bounds for each requested subsection of the
.u_boot_list section. Each such subsection thus contains __start and
__end entries at the begining and end respecitively.

This allows for simple run-time traversing of the array, since the
symbols are properly defined.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Joe Hershberger <joe.hershberger@gmail.com>
Cc: Mike Frysinger <vapier@gentoo.org>

Support the DesginWare MMC Controller.

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Rajeshawari Shinde <rajeshwari.s@samsung.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>

Some of the boards still used the old PXA_MMC driver instead of the
new generic one. Use the new one instead so the old can be removed
and the generic MMC framework can be properly used.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Andy Fleming <afleming@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>