Commit Graph

23164 Commits

Author SHA1 Message Date
Tom Rini 9c1d0e9f16 Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze 2014-02-04 11:51:20 -05:00
Tom Rini c3a6e51c6f Merge branch 'clk' of git://www.denx.de/git/u-boot-microblaze 2014-02-04 11:51:20 -05:00
Tom Rini b66af14dc9 Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx 2014-02-04 11:51:20 -05:00
Stephen Warren c61d94d860 pxe: implement fdtdir extlinux.conf tag
People who write (or scripts that auto-generate) extlinux.conf don't
want to know about HW-specific information such as FDT filenames. Create
a new extlinux.conf tag "fdtdir" that specifies only the directory where
FDT files are located, and defer all knowledge of the filename to U-Boot.
The algorithm implemented is:

==========
if $fdt_addr_r is set:
  if "fdt" tag was specified in extlinux.conf:
    load the FDT from the filename in the tag
  else if "fdtdir" tag was specified in extlinux.conf:
    if "fdtfile" is set in the environment:
      load the FDT from filename in "$fdtfile"
    else:
      load the FDT from some automatically generated filename

if no FDT file was loaded, and $fdtaddr is set:
  # This indicates an FDT packaged with firmware
  use the FDT at $fdtaddr
==========

A small part of an example /boot/extlinux.conf might be:

==========
LABEL primary
        LINUX zImage
        FDTDIR ./

LABEL failsafe
        LINUX bkp/zImage
        FDTDIR bkp/
==========

... with /boot/tegra20-seaboard.dtb or /boot/bkp/tegra20-seaboard.dtb
being loaded by the sysboot/pxe code.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
2014-02-04 11:51:18 -05:00
Stephen Warren f43c401b72 pxe: support "devicetree" tag
The specification for extlinux.conf[1] states that "fdt" is an alias for
"devicetree". To date, U-Boot only implements "fdt". Rectify that.

[1] http://freedesktop.org/wiki/Specifications/BootLoaderSpec/

Signed-off-by: Stephen Warren <swarren@nvidia.com>
2014-02-04 11:51:18 -05:00
Michal Simek 8c3bd6b596 serial: uartlite: Reset RX/TX in init
Just to be sure that there is no pending data.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2014-02-04 16:48:57 +01:00
Michal Simek 6f9b93723a net: axi_emac: Check if phy was correctly detected
As tsec and fm drivers checking phydev->link
ensure that u-boot don't try access device if link is not ready.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2014-02-04 16:42:45 +01:00
Michal Simek 9d24274509 microblaze: Add SPL support
Add support for U-BOOT SPL. NOR and RAM mode are supported.
There are 3 images in NOR flash. u-boot.img, dtb and kernel.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2014-02-04 16:39:50 +01:00
Michal Simek 22ff7f4d19 microblaze: Enable buffer write for NOR flashes
It speeds up writing a lot.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2014-02-04 16:39:37 +01:00
Michal Simek ef2c1d8583 microblaze: Report priviledged or stack protection exception
Just list one more exception.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2014-02-04 16:39:25 +01:00
Michal Simek 6ba64f24a4 microblaze: Show u-boot banner
It is nice to see u-boot version.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2014-02-04 16:39:25 +01:00
Michal Simek 08d0d6f32e common: Add new clk command
Command provides just dump subcommand for showing clock
frequencies in a soc.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Stefano Babic <sbabic@denx.de>
2014-02-04 16:32:20 +01:00
Jim Lin 7bc5c8c930 ARM: tegra: fix "bootp" issue for Tegra124 too
Fix the timeout issue after running "bootp" command in U-Boot console.

TXFIFOTHRES bits of TXFILLTUNING register should be set to 0x10 after a
controller reset and before RUN bit is set (per technical reference
manual).

Signed-off-by: Jim Lin <jilin@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:47 -07:00
Tom Warren f7dc4ac37c ARM: tegra: add Venice2 (Tegra124) board
These are the board files for Venice2 (Tegra124), plus the AS3722 PMIC
files. PMIC init will be moved to pmic_common_init later.

This builds/boots on Venice2, SPI/MMC/USB/I2C all work. Audio, display
and WB/LP0 are not supported yet.

Signed-off-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:47 -07:00
Tom Warren a57c5846a2 ARM: tegra: add DT files for Tegra124 and Venice2
These are fairly complete, and near-clones of Tegra114 Venice, with an
additional I2C port, and MMC address changes for Tegra124.

Signed-off-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:47 -07:00
Tom Warren 2f5dac9214 ARM: tegra: add common (shared) CPU files
These files are used by both SPL and main U-Boot.

Signed-off-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:46 -07:00
Tom Warren 52ef43b052 ARM: tegra: Add CPU (armv7) files for Tegra124
These files are for code that runs on the CPU (A15) on Tegra124 boards.
At this time, there is no A15-specific code here. The warmboot/LP0 files
aren't included as that code hasn't been ported yet.

Signed-off-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:46 -07:00
Tom Warren 32edd2ede2 ARM: tegra: add SPL/AVP (arm720t) CPU files for Tegra124
This provides SPL support for Tegra124 boards - AVP early init, plus
CPU (A15) init/jump to main U-Boot.

Signed-off-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:46 -07:00
Tom Warren 999c6baf79 ARM: tegra: add/edit headers for Tegra124
These headers define the Tegra124 hardware. Add them to the usual
place.

Add Tegra124 chip ID/SKU ID definitions to common headers.

There's no real HW change on Tegra124 for 90% of the toys, so it might
make sense for a future patch to unify some of the content of these
files in a common location.

Signed-off-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:46 -07:00
Stephen Warren 49941b22ec ARM: tegra: fix a typo in the tegra114.dtsi
The reg property for node spi@7000d800 was wrong. Fix it to match the
HW. This change was verified against the Linux kernel.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:46 -07:00
Tom Warren dcd12518b1 ARM: tegra: only build __pinmux_nand() when it's needed
__pinmux_nand() won't compile if PERIPH_ID_NDFLASH isn't defined.
Prevent this from causing build problems on newer SoCs without NAND
support (or without SW support for NAND yet), but preventing
compilation unless the function will actually be used, i.e. when
CONFIG_TEGRA_NAND is defined.

Signed-off-by: Tom Warren <twarren@nvidia.com>
[swarren, rewrote commit description, moved ifdef around whole function
rather than just body]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:46 -07:00
Stephen Warren a4bcd67c72 ARM: tegra: remove a conditional for CSITE rate
There's already an SoC-specific conditional in cpu.h to determine the
PLLP rate. Define the CSITE clock rate inside the same conditional, so
that we can remove a conditional from clock_enable_coresight(). This
means one less place to update the code for new SoCs.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:46 -07:00
Stephen Warren 41447fb2cf ARM: tegra: enable PLLX only once it's been fully configured
This programming sequence is correct per Jimmy Zhang, and makes sense
too!

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:46 -07:00
Stephen Warren cad38a57d3 ARM: tegra: pass just partition ID to power_partition()
Pass just the partition ID to power_partition(), rather than also passing
the partition's status register mask too. This makes it simpler to get
call-sites correct, since they don't need to pass two different values
that define the same thing and must match.

Consequently, we can remove the mask definitions from pmc.h.

Suggested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:46 -07:00
Stephen Warren 41cd530d6d ARM: tegra: misc cleanups triggered by Tegra124 review
Use a named constant for the PLL lock bit in enable_cpu_clocks().

Construct the complete value of pmc_pwrgate_toggle, rather than doing a
read-modify-write; the register is simple enough and doesn't need to
maintain state between operations.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:46 -07:00
Stephen Warren a73ca4789f mmc: tegra: support Tegra124
Tegra124's MMC controller is very similar to earlier SoC generations,
and can be supported by the same driver.

However, there are some non-backwards-compatible HW differences, and
hence a new DT compatible value must be used to describe the HW. This
patch updates the driver to support that new compatible value.

That said, the HW differences are only relevant when enabling certain
high-performance transfer modes. Since the driver is currently very
simple and doesn't enable those modes, we don't actually need to address
any of these HW differences in the code yet, hence the simple nature of
this patch.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:45 -07:00
Jimmy Zhang b9dd6215ce ARM: tegra: don't exceed AVP limits when configuring PLLP
Based on the Tegra TRM, the system clock (which is the AVP clock) can
run up to 275MHz. On power on, the default sytem clock source is set to
PLLP_OUT0. In function clock_early_init(), PLLP_OUT0 will be set to
408MHz which is beyond system clock's upper limit.

The fix is to set the system clock to CLK_M before initializing PLLP,
and then switch back to PLLP_OUT4, which has an appropriate divider
configured, after PLLP has been configured

Implement this logic in new function tegra30_set_up_pllp(),
which sets up PLLP and all PLLP_OUT* dividers, and handles the AVP
clock switching. Remove the duplicate PLLP setup from pllx_set_rate()
and adjust_pllp_out_freqs().

Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
[swarren, significantly refactored the change]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:45 -07:00
Stephen Warren 9399e540ca ARM: tegra: amend pmc.h for Tegra114+
Tegra114 and later's PMC module removes the pwrgate_timer_on register
and replaces it with a clamp_status register. Adjust pmc.h to reflect
this, and update any code affected by the change.

The cpu.c change in this patch was extracted from a much larger patch
by Jimmy Zhang. The pmc.h change was written from scratch, but inspired
by related changes made by Tom Warren.

There could well be other differences in the PMC register set for chips
after Tegra20/30. However, they don't affect the code in U-Boot at
present, so I haven't attempted an exhaustive update of pmc.h.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:45 -07:00
Tom Warren c82014daf5 ARM: tegra: implement MASK_BITS_31_29
Some clock sources have 3-bit muxes in bits 31:29. Implement core
support for this mux field.

Signed-off-by: Tom Warren <twarren@nvidia.com>
[swarren, extracted from a larger patch by Tom]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:45 -07:00
Stephen Warren 04b8e8e745 ARM: tegra: MASK_BITS_ no longer needs specific values
Since all code that sets or interprets MASK_BITS_* now uses the enums
to define/compare the values, there is no need for MASK_BITS_* to have
a specific integer value. In fact, having a specific integer value may
encourage people to hard-code those values, or interpret the values in
incorrect ways.

As such, remove the logic that assigns a specific value to the enum
values in order to make it completely clear that it's just an enum, not
something that directly represents some integer value.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:45 -07:00
Stephen Warren 54d2e18292 ARM: tegra: use MASK_BITS_* macros everywhere
Not all code that set or interpreted "mux_bits" was using the named
macros, but rather some was simply using hard-coded integer constants.
This makes it hard to determine which pieces of code are affected by
changes to those constants.

Replace the integer constants with the equivalent macro definitions so
that everything is nicely tied together.

Note that I'm not convinced all the code was using the correct integer
constants, and hence I'm not convinced that all the code is now using
the desired macros. However, this change is a purely mechanical
replacement and should have no functional change. Fixing any bugs will
come later, separately.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:45 -07:00
Stephen Warren 9cb0c6dc69 ARM: tegra: rename OUT_CLK_SOURCE_*
OUT_CLK_SOURCE_ are currently named after the number of bits the mask
they represent includes. However, bit count is not the only possible
variable; bit position may also vary. Rename OUT_CLK_SOURCE_ to
OUT_CLK_SOURCE_31_30_ and OUT_CLK_SOURCE4_ to OUT_CLK_SOURCE_31_28 to
more completely describe exactly what they represent, without having to
go look up the definitions.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:45 -07:00
Stephen Warren 5916a36ee9 ARM: tegra: rename MASK_BITS_29_28 to MASK_BITS_31_28
The only place where the MASK_BITS_* values are used is in
adjust_periph_pll(), which interprets the value 4 (old MASK_BITS_29_28,
new MASK_BITS_31_28) as being associated with mask OUT_CLK_SOURCE4_MASK,
i.e. bits 31:28. Rename the MASK_BITS_ macro to reflect how it's actually
implemented.

Note that no Tegra clock register actually uses all of bits 31:28 as
the mux field. Rather, bits 30:28, 29:28, or 28 are used. However, in
those cases, nothing is stored in the bits above the mux field, so it's
safe to pretend that the mux field extends all the way to the end of the
register. As such, the U-Boot clock driver is currently a bit lazy, and
doesn't distinguish between 31:28, 30:28, 29:28 and 28; it just lumps
them all together and pretends they're all 31:28. This patch doesn't
cause this issue; it was pre-existing. Hopefully, future patches will
clean this up.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:45 -07:00
Tom Warren 0b01b53aa5 ARM: tegra: deduplicate MASK_BITS_xxx clock mux enum
The enum used to define the set of register bits used to represent a
clock's input mux, MUX_BITS_*, is defined separately for each SoC at
present. Move this definition to a common location to ease fixing up
some issues with the definition, and the code that uses it.

Signed-off-by: Tom Warren <twarren@nvidia.com>
[swarren, extracted from a larger patch by Tom]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:44 -07:00
Stephen Warren 09266b270f ARM: tegra: clear $usb_need_init each boot
$usb_need_init prevents "usb start" from being run multiple times for
each boot attempt, i.e. once for USB storage, another for PXE, and
another for DHCP. However, the flag that's used to determine when to run
"usb start" is never cleared, so a subsequent "boot" command will never
probe for a freshly plugged in USB device. Fix this so that new USB
devices will be probed once per boot attempt.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:44 -07:00
Stephen Warren b9b53a60ae ARM: tegra: set env vars to indicate Cardhu A04 support
The U-Boot "cardhu" build supports only revision 4 of the Cardhu board
and later compatible revisions. Hence, set $board_name in the default
environment to "cardhu-a04" rather than just "cardhu".

The Linux kernel has separate DTs for Cardhu A02 and A04, although the
former isn't really supported any more. Consequently, the kernel DT file
that matches the U-Boot cardhu build is "tegra30-cardhu-a04.dtb" rather
than "tegra30-cardhu.dtb". Set the $fdtfile default environment variable
to reflect this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:44 -07:00
Stephen Warren 86b657878b ARM: tegra: accept any SKU ID for most chips
For Tegra20, the SKU ID actually impacts how U-Boot programs the chip,
and hence we need to explicitly know about each and every SKU ID in order
to operate correctly.

However, for Tegra30/114, this isn't the case. Rather than forcing each
new user with a different SKU to manually add their SKU ID into the code,
simply accept any SKU ID.

If U-Boot ever starts e.g. programming maximal CPU clocks etc., we'll
need to undo this, or make the default case map to conservative defaults,
but for now it's likely the path to least support cost.

Reported-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2014-02-03 09:46:44 -07:00
Prabhakar Kushwaha 1b4175d6fa driver/ifc:Change accessor function to take care of endianness
IFC registers can be of type Little Endian or big Endian depending upon
Freescale SoC. Here SoC defines the register type of IFC IP.

So update acessor functions with common IFC acessor functions to take care
both type of endianness.

Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Acked-by: York Sun <yorksun@freescale.com>
2014-02-03 08:38:51 -08:00
Valentin Longchamp 27c78e06f2 kmp204x: initial support for PCIe FPGA configuration
The PEXHC PCIe configuration mechanism ensures that the FPGA get
configured at power-up. Since all the PCIe devices should be configured
when the kernel start, u-boot has to take care that the FPGA gets
configured also in other reset scenarios, mostly because of possible
configuration change.

The used mechanism is taken from the km_kirkwood design and adapted to
the kmp204x case (slightly different HW and PCIe configuration).

Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Reviewed-by: York Sun <yorksun@freescale.com>
2014-02-03 08:38:51 -08:00
Valentin Longchamp 47c1180c02 kmp204x: enable support for SPANSION SPI NOR
The new prototype and the final series was moved from Micron to Spansion
to have a better reset sequence that is easier to support.

Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Reviewed-by: York Sun <yorksun@freescale.com>
2014-02-03 08:38:50 -08:00
Valentin Longchamp cf7707a1df KM: add the KM_UBI_PART_BOOT_OPTS #define
This define can be used if the ubi boot partition (defined for all
Keymile boards with KM_UBI_PARTITION_NAME_BOOT #define to ubi0) needs
some additionnal boot options.

This is the case for the kmp204x boards since u-boot does not support
NAND Flash subpage accesses on this platform, an additionnal argument
that defines the VID offstet must be given to the kernel.

The UBI cmd line option now looks like this "ubi.mtd=ubi0,2048" on this
platform.

Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Reviewed-by: York Sun <yorksun@freescale.com>
2014-02-03 08:38:50 -08:00
Valentin Longchamp 1f07a71b96 kmp204x: update I2C field of RCW
On the previous HW revision (now unsupported), there was a need for
external DMA signals and thus the I2C3/4 signals were used
DMA1_DONE/ACK/REQ.

These signals now are configured as GPIO[16:19].

Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Reviewed-by: York Sun <yorksun@freescale.com>
2014-02-03 08:38:50 -08:00
Valentin Longchamp e95bbc8bac kmp204x: add support for the kmcoge4 board
The kmcoge4 board is the product board derived from the kmlion1
prototype. The main difference between the 2 boards is that the kmcoge4
does not configure the Local Bus controller for LCS2.

Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
[York Sun: Minor change to boards.cfg to keep targets in order]
Signed-off-by: York Sun <yorksun@freescale.com>
2014-02-03 08:38:50 -08:00
Valentin Longchamp fabb9297fa kmp204x: implement workaround for A-006559
According to the errata, some bits of an undocumented register in the
DCSR must be set for every core in order to avoid a possible data or
instruction corruption.

This is required for the 2.0 revision of the P2041 that should be used
as soon as available in our design.

Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Reviewed-by: York Sun <yorksun@freescale.com>
2014-02-03 08:38:50 -08:00
Rainer Boschung f3e74d0a9f kmp204x: I2C deblocking support
This patch adds support for using some GPIOs that are connected to the
I2C bus to force the bus lines state and perform some bus deblocking
sequences.

The KM common deblocking algorithm from board/keymile/common/common.c is
used. The GPIO lines used for deblocking the I2C bus are some external
GPIOs provided by the QRIO CPLD:
  - SCL = GPIOA_20
  - SDA = GPIOA_21

The QRIO GPIOs act in an open-drain-like manner, for 0 the line is
driven low and for 1 the GPIO is set as input and the line gets
pulled-up.

Signed-off-by: Rainer Boschung <rainer.boschung@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Reviewed-by: York Sun <yorksun@freescale.com>
2014-02-03 08:38:50 -08:00
Valentin Longchamp 87ea2c0ff3 kmp204x: introduce QRIO GPIO functions
The QRIO GPIO functions can be of general interest. They are thus added
to a qrio.c and their prototype are available from kmp204x.h. The QRIO
prst function are also included in this file, as well as the functions
required for the I2C deblocking support (open-drain).

Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
[York Sun: Remove extra blank line in board/keymile/kmp204x/qrio.c]
Signed-off-by: York Sun <yorksun@freescale.com>
2014-02-03 08:38:49 -08:00
Rainer Boschung dd21f09669 kmp204x: support for QRIO1 bootcounter
Make use of the QRIO1 32bit register at 0x20 as bootcounter register
Check for BOOTCOUNT_MAGIC pattern when before bootcounter value is read

Signed-off-by: Rainer Boschung <rainer.boschung@keymile.com>
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
[York Sun: Minor change to commit message]
Signed-off-by: York Sun <yorksun@freescale.com>
2014-02-03 08:38:49 -08:00
Priyanka Jain 714fd406da powerpc/t104xrdb: Add basic ethernet support
This covers only non-L2 switch ethernet interfaces i.e.
RGMII and SGMII interface for both T1040RDB and T1042RDB_PI

T1040RDB is configured as serdes protocol 0x66 which can
support following interfaces
    2 RGMIIS on DTSEC4, DTSEC5
    1 SGMII on DTSEC3

T1042RDB_PI is configured as serdes protocol 0x06 which can
support following interfaces
    2 RGMIIS on DTSEC4, DTSEC5

Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
[York Sun: Minor change in commit message]
Signed-off-by: York Sun <yorksun@freescale.com>
2014-02-03 08:38:49 -08:00
Nikhil Badola a4f7cba64e powerpc/usb: Enable dual phy for T1040
Define CONFIG_SYS_FSL_USB_DUAL_PHY_ENABLE macro for enabling dual
phy in t1040

Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
2014-02-03 08:38:49 -08:00
Prabhakar Kushwaha 48aee3913d powerpc/t104xrdb: Update T1042RDB.h in config folder
Add usb2 node entry to hwconfig default

Remove DDR controller interleaving from hwconfig

Move SPI related macros out of "#ifdef CONFIG_SPIFLASH"

Add CONFIG_SYS_CSPR2_EXT to make CPLD accessible in u-boot

Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
[York Sun: Fix commit message]
Signed-off-by: York Sun <yorksun@freescale.com>
2014-02-03 08:38:49 -08:00