This prevents the preprocessor from complaining when processing
variadic macros

Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Graeme Russ <graeme.russ@gmail.com>

U-boot needs a host controller or "hose" to interact with the PCI busses
behind them. This change installs a host controller during initialization of
the coreboot "board" which implements some of X86's basic PCI semantics. This
relies on some existing generic code, but also duplicates a little bit of code
from the sc520 implementation. Ideally we'd eliminate that duplication at some
point.

It looks like in order to scan buses beyond bus 0, we'll need to tell u-boot's
generic PCI configuration code what to do if it encounters a bridge,
specifically to scan the bus on the other side of it.

Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Graeme Russ <graeme.russ@gmail.com>

coreboot.c and coreboot_pci.c don't contain board specific but only
coreboot specific code. Hence move it to the coreboot directory in
arch/x86/cpu (which should probably be moved out of cpu/ in another
commit)

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

I suspect these includes were usually available because something else
included them earlier or because they were brought in transitively.

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

When running from coreboot we don't want this code.

This version works by ifdef-ing out all of the code that would go
into those sections and all the code that refers to it. The sections are
then empty, and the linker will either leave them empty for the loader
to ignore or remove them entirely.

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

These are available on other architectures, so add them on x86.

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

ilog2 is required by AHCI driver

Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

Putting global data on the stack simplifies the init process (and makes it
slightly quicker). During the 'flash' stage of the init sequence, global
data is in the CAR stack. After SDRAM is initialised, global data is copied
from CAR to the SDRAM stack

Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

So it can be used as a type in struct global_data and remove an ugly typecast

Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>

At some point, a confusion arose about the use of the bit
definitions in host_caps for bus widths, and the value
in ext_csd. By coincidence, a simple shift could convert
between one and the other:

MMC_MODE_1BIT = 0, EXT_CSD_BUS_WIDTH_1 = 0
MMC_MODE_4BIT = 0x100, EXT_CSD_BUS_WIDTH_4 = 1
MMC_MODE_8BIT = 0x200, EXT_CSD_BUS_WIDTH_8 = 2

However, as host_caps is a bitmask of supported things,
there is not, in fact, a one-to-one correspondence. host_caps
is capable of containing MODE_4BIT | MODE_8BIT, so nonsensical
things were happening where we would try to set the bus width
to 12.

The new code clarifies the very different namespaces:

host_caps/card_caps = bitmask (MMC_MODE_*)
ext CSD fields are just an index (EXT_CSD_BUS_WIDTH_*)
mmc->bus_width integer number of bits (1, 4, 8)

We create arrays to map between the namespaces, like in Linux.

Signed-off-by: Andy Fleming <afleming@freescale.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Stephen Warren <swarren@nvidia.com>

If a malformed 'read' or 'write' command is issued, the Sandbox U-Boot
can crash because the command-handling code does no error checking on
the number of provided arguments.

This change makes the mmc 'erase', 'read' and 'write' commands only
function if the proper number of arguments are supplied.

Also puts the else assignment at the beginning fo the if() statement
to shortens the generated code.  This removes an unnecessary jump from
the generated code.

Signed-off-by: Taylor Hutt <thutt@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andy Fleming <afleming@freescale.com>

Tegra's MMC driver does DMA, and hence needs cache-aligned buffers. In
some cases (e.g. user load commands) this cannot be guaranteed by callers
of the MMC APIs. To solve this, modify the Tegra MMC driver to use the
new bounce_buffer_*() APIs.

Note: Ideally, all U-Boot code will always provide address- and size-
aligned buffers, so a bounce buffer will only ever be needed for user-
supplied buffers (e.g. load commands). Ensuring this removes the need
for performance-sucking bounce buffer cache management and memcpy()s.
The one known exception at present is the SCR buffer in sd_change_freq(),
which is only 8 bytes long. Solving this requires enhancing struct
mmc_data to know the difference between buffer size and transferred data
size, or forcing all callers of mmc_send_cmd() to have allocated buffers
using ALLOC_CACHE_ALIGN_BUFFER(), which while true in this case, is not
enforced in any way at present, and so cannot be assumed by the core MMC
code.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andy Fleming <afleming@freescale.com>

The current bouncebuf API requires all parameters to be passed to both
bounce_buffer_start() and bounce_buffer_stop(). Modify the bouncebuf
start function to accept a state structure as a parameter, and only
require that state struct to be passed to the stop function. This
simplifies usage of the bounce buffer by clients.

Don't modify the data pointer, but rather store the temporary buffer in
this state struct. The bouncebuf code ensures that client code can
always use a single buffer pointer in the state structure, irrespective
of whether a bounce buffer actually had to be allocated.

Move cache management logic into the bounce buffer code, so that each
client doesn't have to duplicate this. I believe there's no need to
invalidate the buffer before a DMA operation, since flushing the cache
should prevent any write-backs.

Update the MXS MMC driver for this change.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andy Fleming <afleming@freescale.com>

If any driver ever needs to use the bounce buffer API, it always needs
to use it. As such, providing a dummy implementation of those APIs when
CONFIG_BOUNCE_BUFFER isn't defined does not make sense. Remove the dummy
implementation.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andy Fleming <afleming@freescale.com>

Commits 6dc71c8d "MMC: MXS: Toggle the generic bounce buffer on the
boards" and 49a627f8 "MMC: Remove the MMC bounce buffer" replaced
CONFIG_MMC_BOUNCE_BUFFER with CONFIG_BOUNCE_BUFFER, but missed
converting a few boards over to the new option. Fix this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andy Fleming <afleming@freescale.com>

Bring in the code from Linux kernel.

Added to Linux kernel by:
commit e08c1694d9e2138204f2b79b73f0f159074ce2f5
Author: Andres Salomon <dilinger@queued.net>
Date:   Fri Jul 4 10:00:03 2008 -0700

Some HW balks when writing both voltage setting and power up at the same
time to SDHCI_POWER_CONTROL register.

Signed-off-by: Rommel G Custodio <sessyargc@gmail.com>
CC: Andy Fleming <afleming@freescale.com>

v2: fix attribution and SOB
Signed-off-by: Andy Fleming <afleming@freescale.com>

Signed-off-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Andreas Bießmann <andreas.devel@googlemail.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>

The interpretation of the data returned by the MMC_CMD_ALL_SEND_CID
command was incorrect with respect to the JEDEC Standard No. 84-A441.

This change makes the interpretation correct with respect to the
defined fields of the CID register.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Taylor Hutt <thutt@chromium.org>
Signed-off-by: Andy Fleming <afleming@freescale.com>

Support DesignWare MMC Controller for Samsung Specific.

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>

usbdescriptors.h conflicts with linux/usb/ch9.h
Remove it.

Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>

This patch adds a NAND Flash torture feature, which is useful as a block stress
test to determine if a block is still good and reliable (or should be marked as
bad), e.g. after a write error.

This code is ported from mtd-utils' lib/libmtd.c.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Cc: Scott Wood <scottwood@freescale.com>
[scottwood@freescale.com: removed unnec. ifdef and unwrapped error strings]
Signed-off-by: Scott Wood <scottwood@freescale.com>

NAND Flash is erased by blocks, not by pages.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Cc: Scott Wood <scottwood@freescale.com>

This patch cleans up nand_util.c:
 - Fix tabs.
 - Fix typos.
 - Remove space character before opening parenthesis in function calls.
 - Fix comments.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Cc: Scott Wood <scottwood@freescale.com>

Use a flag instead of a hard-coded macro so that sub-page reads can be
enabled in other cases (such as on-die ecc).

This is the same as a5ff4f102937a3492bca4a9ff0c341d78813414c in Linux

Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>

IFC-1.1.0 uses 28nm techenology for SRAM. This tech has known limitaion for
SRAM i.e. "byte select" is not supported. Hence Read Modify Write is
implemented in IFC for any "system side write" into sram buffer. Reading an
uninitialized memory results in ECC Error from sram wrapper.

Hence we must initialize/prefill SRAM buffer by any data before writing
anything in SRAM from system side. To initialize SRAM user can use "READID"
NAND command with read bytes equal to SRAM size. It will be a one time
activity post boot

Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
[scottwood@freescale.com: fix fsl_ifc_sram_init prototype]
Signed-off-by: Scott Wood <scottwood@freescale.com>

Reference nand monitor commands in U-Boot README

Signed-off-by: Karl O. Pinc <kop@meme.com>

These controllers can only do hardware ECC on full page transfers.

Signed-off-by: Scott Wood <scottwood@freescale.com>

This allows DDR configuration to be deferred to the final U-Boot image,
which is able to make use of SPD data.  The SPL itself cannot use SPD due
to code size constraints.  It previously used fixed register values for
DDR configuration, and those values did not work on the p2020rdb-pca
board I tested with.  It's possible that different revisions of the board
require different settings.  Using SPD eliminates that problem.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Andy Fleming <afleming@freescale.com>

- Sort by address, and fix column alignment

- Don't label things as localbus that aren't.  Instead, put chipselect
  info at the end of the description for localbus windows.  Note that
  NAND/NOR have their chipselects swapped when booting from NAND, and CS2
  can be either PMC or VSC7385 depending on hwconfig.

- Shrink NAND to the 32K that's actually mapped in the localbus

- Assign an address and size to L2 SRAM.  Remove the similarly named
  but unintelligible "L2 SDRAM(REV.)".

- Remove the untrue comment about L1 stack being mapped with TLB0.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Andy Fleming <afleming@freescale.com>

Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Andy Fleming <afleming@freescale.com>

Document parameters used for specifying the NAND image to be loaded.

Also fix the definition of CONFIG_SPL_NAND_SIMPLE -- it's only
nand_spl_simple.c, not the entire nand directory.  The word "simple" is
there for a reason.  :-)

Signed-off-by: Scott Wood <scottwood@freescale.com>
---
v2: updated for makefile changes earlier in patchset

Some small SPLs do not use nand_base.c, and a subset of those also
require a special driver.  Some SPLs need software ECC but others can't
fit it.

All existing boards that specify CONFIG_SPL_NAND_SUPPORT have these
symbols added to preserve existing behavior.

Signed-off-by: Scott Wood <scottwood@freescale.com>
--
v2: use positive logic for including bits of NAND, rather than
a MINIMAL symbol that excludes things.

Introduces CONFIG_SPL_RELOC_TEXT_BASE and CONFIG_SPL_RELOC_STACK.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Andy Fleming <afleming@freescale.com>

Update CONFIG_RAMBOOT and CONFIG_NAND_SPL references to accept CONFIG_SPL
and CONFIG_SPL_BUILD, respectively.  CONFIG_NAND_SPL can be removed once
the last mpc85xx nand_spl target is gone.

CONFIG_RAMBOOT will need to remain for other use cases, but it doesn't
seem right to overload it for meaning SPL as well as nand_spl does.  Even
if it's somewhat appropriate for the main u-boot, the SPL itself isn't
(necessarily) ramboot, and we don't have separate configs for SPL and
main u-boot.  It was also inconsistent, as other platforms such as
mpc83xx didn't use CONFIG_RAMBOOT in this way.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Andy Fleming <afleming@freescale.com>

cpu_init_nand.c is renamed to spl_minimal.c as it is not really NAND-specific.

Signed-off-by: Scott Wood <scottwood@freescale.com>
---
v2: factor out START, and change cpu_init_nand.c to spl_minimal.c
Cc: Andy Fleming <afleming@freescale.com>

A subsequent patch will conditionalize some of the files that are
currently unconditional.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Andy Fleming <afleming@freescale.com>

There is nothing really NAND-specific about this file.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Andy Fleming <afleming@freescale.com>