This adds support for Bluegiga APX4 Development Kit. It is built around
Freescale i.MX28. Currently supported features are: ethernet, I2C, MMC,
RTC and USB. APX4 has only one ethernet port.
Signed-off-by: NVeli-Pekka Peltola <veli-pekka.peltola@bluegiga.com>
Signed-off-by: NLauri Hintsala <lauri.hintsala@bluegiga.com>
Cc: Stefano Babic <sbabic@denx.de>

The information now is gathered from HW_DIGCTL_CHIPID register and
includes the chip modem and revision on the output.
Signed-off-by: NOtavio Salvador <otavio@ossystems.com.br>

The DMA transfers happen only if the transfered data are larger
than 512 bytes. Otherwise PIO is used. This is a small speed
optimization.

The DMA transfer doesn't work if unaligned transfer is requested
due to the limitation of the DMA controller. This has to be fixed
by introducing generic bounce buffer. Therefore the DMA feature
is now disabled by default.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>

Pull out all the PIO transfer logic into separate function,
so DMA can be added.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>

This makes it easier to adapt for addition of DMA support.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Wolfgang Denk <wd@denx.de>

In case an unidentified CPU type is detected it now returns
i.MX??, in a const char.
Signed-off-by: NOtavio Salvador <otavio@ossystems.com.br>
Cc: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>

This adds support for the AT91SAM9G20 boards by taskit GmbH.
Both boards, Stamp9G20 and PortuxG20, are integrated in one
file. PortuxG20 is basically a SBC built around the Stamp9G20.
Signed-off-by: NMarkus Hubig <mhubig@imko.de>
Cc: Andreas Bießmann <andreas.devel@googlemail.com>
Signed-off-by: NAndreas Bießmann <andreas.deve@googlemail.com>

Signed-off-by: NMarkus Hubig <mhubig@imko.de>
Cc: Andreas Bießmann <andreas.devel@googlemail.com>
Signed-off-by: NAndreas Bießmann <andreas.devel@googlemail.com>

The grasshopper board is a avr32 based device and belongs therefore to the avr32
section.
Signed-off-by: NAndreas Bießmann <andreas.devel@googlemail.com>

These boards have ARM cores, move to the ARM section.
Signed-off-by: NAndreas Bießmann <andreas.devel@googlemail.com>

Add at91sam9x5ek board support, this board support the following SoCs
  AT91SAM9G15, AT91SAM9G25, AT91SAM9G35, AT91SAM9X25, AT91SAM9X35

Using at91sam9x5ek_nandflash to configure for the board
Now only supports NAND with software ECC boot up
Signed-off-by: NBo Shen <voice.shen@atmel.com>
[move MAINTAINERS entry to right place]
Signed-off-by: NAndreas Bießmann <andreas.devel@googlemail.com>

Signed-off-by: NAndreas Bießmann <andreas.devel@googlemail.com>

Beaglebone uses SMSC PHY which works incorrectly with generic PHY
driver so enable SMSC PHY driver to fix networking problems on
Beaglebone.
Signed-off-by: NIlya Yanok <ilya.yanok@cogentembedded.com>

The total RAM size of the IGEP-based boards is 512MiB not 1GiB, the
LPDDR memory consist on two dies of 256MiB.
Signed-off-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Tested-by: NJavier Martinez Canillas <javier@dowhile0.org>

For the DA8xx family of SoCs, the set_cpu_clk_info() function was not
initialising the DSP frequency, leading to 'bdinfo' command output such as:

  [...snip...]
  ARM frequency = 300 MHz
  DSP frequency = -536870913 MHz
  DDR frequency = 300 MHz

This commit provides a separate implementation of set_cpu_clk_info() for
the DA8xx SoCs that initialises the DSP frequency to zero (since
currently the DSP is not enabled by U-Boot on any DA8xx platform). The
separate implementation is justified because there is no common code
between DA8xx and the other SoC families. It is now much easier to
understand the flow of the two separate functions.
Signed-off-by: NLaurence Withers <lwithers@guralp.com>
Cc: Tom Rini <trini@ti.com>
Cc: Hadli, Manjunath <manjunath.hadli@ti.com>
Cc: Heiko Schocher <hs@denx.de>

Replace a magic number for the DDR2/mDDR PHY clock ID with a proper
definition. In addition, don't request this clock ID on DA830 hardware,
which does not have a DDR2/mDDR PHY (or associated PLL controller).
Signed-off-by: NLaurence Withers <lwithers@guralp.com>
Cc: Tom Rini <trini@ti.com>
Cc: Prabhakar Lad <prabhakar.csengg@gmail.com>

On the DA830, UART2's clock is derived from PLL controller 0 output 2.
On the DA850, it is in the ASYNC3 group, and may be switched between PLL
controller 0 or 1. Fix the definition of the ID to match.
Signed-off-by: NLaurence Withers <lwithers@guralp.com>
Cc: Tom Rini <trini@ti.com>
Cc: Prabhakar Lad <prabhakar.csengg@gmail.com>

Tidy up the clock IDs defined for the DA8xx SOCs. With this new structure in
place, it is clear how to define new clock IDs, and how these map to the
numbers presented in the technical reference manual.
Signed-off-by: NLaurence Withers <lwithers@guralp.com>
Cc: Tom Rini <trini@ti.com>
Cc: Prabhakar Lad <prabhakar.csengg@gmail.com>
Signed-off-by: NTom Rini <trini@ti.com>

Remove Sandeep, thanks for all the hard work!
Signed-off-by: NTom Rini <trini@ti.com>

Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: U-Boot DM <u-boot-dm@lists.denx.de>
Cc: Tom Rini <trini@ti.com>
Acked-by: NTom Rini <trini@ti.com>
Signed-off-by: NTom Rini <trini@ti.com>

This fixes the breakage with SPL on most OMAP boards after the GPIO
driver was moved.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: U-Boot DM <u-boot-dm@lists.denx.de>
Cc: Tom Rini <trini@ti.com>
Acked-by: NTom Rini <trini@ti.com>
Signed-off-by: NTom Rini <trini@ti.com>

- Move definition of the EEPROM contents to <asm/arch/sys_proto.h>
  - Make some defines a little less generic now.
- Pinmux must be done by done by SPL now.
- Create 3 pinmux functions, uart0, i2c0 and board.
- Add pinmux specific to Starter Kit EVM for MMC now.
Signed-off-by: NTom Rini <trini@ti.com>

am33xx boards have at least one eeprom and in the case of beaglebones
with capes, more.
Signed-off-by: NTom Rini <trini@ti.com>

- Board requires gpio0 #7 to be set to power DDR3.
- Board uses DDR3, add a way to determine which DDR type to call
  config_ddr with.
- Both of the above require filling in the header structure early, move
  it into the data section.
Signed-off-by: NTom Rini <trini@ti.com>

The intention has always been (and boards are to support) an i2c EEPROM
that will identify what hardware they are, allowing a single binary to
support multiple boards.  As such, remove the 'evm.c' file as there is
nothing EVM centric in it currently, only SoC peripheral configuration.
Signed-off-by: NTom Rini <trini@ti.com>

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

In order to support DDR3 as well as DDR2, we need to perform the same
init sequence, but with different values.  So change config_ddr() to
toggle setting pointers/etc for what DDR2 wants, and then calling.
Signed-off-by: NTom Rini <trini@ti.com>

We need vtpreg and ddrctrl but no longer need a second ddrregs.
Signed-off-by: NTom Rini <trini@ti.com>

The ddr_regs struct was incorrectly offset after the dt0wiratio0 entry.
Correct this by documenting a missing register that will be used at some
point in the future (when write leveling is supported).  Further, the
cmdNcs{force,delay} fields are undocumented and we have been setting
them to zero, remove.  Next, setting of the
'DATAn_REG_PHY_USE_RANK0_DELAYS field belongs with the rest of the
ddr_data entries, so program it there.  Finally, comment on how we are
configuring the DATA1 registers that correspond to the DATA0 (dt0)
registers defined in the struct.
Signed-off-by: NTom Rini <trini@ti.com>

The various ratio1 fields are not documented in any of the documentation
I can find.  Removing these and testing has yielded success, so remove
the code that sets them and move their locations into the reserved
fields.
Signed-off-by: NTom Rini <trini@ti.com>

This function sets a number of related registers to the same value (the
registers in question all have the same field descriptions and are
related in operation).  Rather than defining a struct and setting the
value repeatedly, just pass in the value.
Signed-off-by: NTom Rini <trini@ti.com>

Rather than defining our own structs to note what to use when
programming the EMIF and related re-use the emif_regs struct.
Signed-off-by: NTom Rini <trini@ti.com>

A number of memory initalization functions were int and always returned
0.  Further it's not feasible to be doing error checking here, so simply
turn them into void functions.
Signed-off-by: NTom Rini <trini@ti.com>

- Remove the call to set ddrctrl->ddrioctrl as it's all zeros.
- Comment what we're really setting in ddrctrl->ddrckectrl which is that
  we're operating in the normal mode where EMIF/PHY clock is controlled
  by the PHY.
Signed-off-by: NTom Rini <trini@ti.com>

EMIF parameters are calculated based on the AC timing
parameters from the SDRAM datasheet and the DDR frequency.

Current values for these paramters in AM335x U-Boot code,
though reliable, are not fully optimal. The most optimal
settings can be derived based on the guidelines published
at [1]. A pre-computed set of values with the most optimum
settings for AM335x EVM and BeagleBone can be found at [2].

[1] http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuration_tips
[2] http://processors.wiki.ti.com/index.php/OMAP_and_Sitara_CCS_support#AM335xSigned-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: NTom Rini <trini@ti.com>

- Remove a handful of unused defines.
- Prefix more values with 'DDR2' as DDR3 will require different values.
Signed-off-by: NTom Rini <trini@ti.com>

Depending on if we have DDR2 or DDR3 on the board we will need to call
ddr_pll_config with a different value.  This call can be delayed
slightly to the point where we know which type of memory we have.
Signed-off-by: NTom Rini <trini@ti.com>

We need to pass in the type of memory that is connected to the board.
The only reliable way to do this is to know what type of board we are
running on (which later will be knowable in s_init()).  For now, pass in
the value of DDR2.
Signed-off-by: NTom Rini <trini@ti.com>

Rework the EMIF4/DDR code slightly to setup the structs that
config_cmd_ctrl and config_ddr_data take to be setup at compile time and
mark them as const.  This lets us simplify the calling path slightly as
well as making it easier to deal with DDR3.
Signed-off-by: NTom Rini <trini@ti.com>

With the previous bugfix we now don't need to set two different REF_CTRL
values and instead set the final value.
Signed-off-by: NTom Rini <trini@ti.com>