The CONFIG_CMD_ENV option controls enablement of the `saveenv` command
rather than a generic "env" command, or anything else related to the
environment.  So, let's make sure the define is named accordingly.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Default CONFIG_CMD_IMLS must be disabled when CONFIG_SYS_NO_FLASH is defined
Signed-off-by: NValeriy Glushkov <gvv@lstec.com>

- Extend ub_dev_read() and ub_dev_recv() so they return the length actually
read, which allows for better control and error handling (this introduces
additional error code API_ESYSC returned by the glue mid-layer).

- Clean up definitions naming and usage.

- Other minor cosmetics.

Note these changes do not touch the API proper, so the interface between
U-Boot and standalone applications remains unchanged.
Signed-off-by: NRafal Jaworowski <raj@semihalf.com>

Signed-off-by: NRafal Czubak <rcz@semihalf.com>

Signed-off-by: NRafal Czubak <rcz@semihalf.com>
Acked-by: NRafal Jaworowski <raj@semihalf.com>

De-hardcode range in RAM we search for the API signature. Instead use the stack
pointer as a hint to narrow down the range in which the signature could reside
(it is malloc'ed on the U-Boot heap, and is hoped to remain in some proximity
from stack area). Adjust PowerPC code in API demo to the new scheme.
Signed-off-by: NRafal Czubak <rcz@semihalf.com>
Signed-off-by: NRafal Jaworowski <raj@semihalf.com>

After introducing redundant environment the kernel images was
overlapping with environment.
Signed-off-by: NWolfgang Denk <wd@denx.de>

Signed-off-by: NAndy Fleming <afleming@freescale.com>

Signed-off-by: NAndy Fleming <afleming@freescale.com>

This uses the new MMC framework

Some contributions by Dave Liu <daveliu@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

Here's a new framework (based roughly off the linux one) for managing
MMC controllers.  It handles all of the standard SD/MMC transactions,
leaving the host drivers to implement only what is necessary to
deal with their specific hardware.

This also hooks the infrastructure into the PowerPC board code
(similar to how the ethernet infrastructure now hooks in)

Some of this code was contributed by Dave Liu <daveliu@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

The current MMC infrastructure relies on the existence of an
arch-specific header file.  This isn't necessary, and a couple
drivers were forced to implement dummy files to meet this requirement.
Instead, we move the stuff in those header files into a more appropriate
place, and eliminate the stubs and the #include of asm/arch/mmc.h
Signed-off-by: NAndy Fleming <afleming@freescale.com>

This is to get it out of the way of incoming MMC framework
Signed-off-by: NAndy Fleming <afleming@freescale.com>

MMC cards are not memory, so we stop treating them that way.
Signed-off-by: NAndy Fleming <afleming@freescale.com>

This errata fix is required for 32 bit DDR2 controller on 8572.
May  also be required for P10XX20XX platforms
Signed-off-by: NPoonam_Agarwal-b10812 <b10812@lc1106.zin33.ap.freescale.net>

The ecm variable in sdram.c was being declared for all 8548, but only
used by specific 8548 boards, so we make that variable require those
specific boards, too

The nand code was using an index "i" into a table, and then re-using "i"
to set addresses for each upm.  However, then it relied on the old value
of i still being there to enable things.  Changed the second "i" to "j"
Signed-off-by: NAndy Fleming <afleming@freescale.com>

This patch adds the workaround for erratum DDR20 according to MPC8548
Device Errata document, Rev. 1: "CKE signal may not function correctly
after assertion of HRESET". Furthermore, the bug DDR19 is fixed in
processor version 2.1 and the work-around must be removed.
Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>

This patch makes accesses to the system memory cachable by removing the
caching-inhibited and guarded flags from the relevant TLB entries for
the TQM8548_BE and TQM8548_AG modules. FYI, the Freescale MPC85* boards
are configured similarly.

This results in a big averall performace improvement. TFTP downloads,
NAND Flash accesses, kernel boots, etc. are much faster.
Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>

This patch add support for the 1 GiB DDR2-SDRAM on the TQM8548_AG
module.
Signed-off-by: NJens Gehrlein <sew_s@tqs.de>
Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>

According to new TQM8548 timing specification:
Refresh Recovery: 34 -> 53 clocks
CKE pulse width:  1 -> 3 cycles
Window for four activities: 13 -> 14 cycles
Signed-off-by: NJens Gehrlein <sew_s@tqs.de>
Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>

The TQM8548_AG is a variant of the TQM8548 module with 1 GiB memory,
CAN and without PCI/PCI-X and RTC. U-Boot can be built for this module
with "$ make TQM8548_AG_config".
Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>

The TQM8548_BE is a variant of the TQM8548 module with NAND and CAN
interface. With NAND support, the image is significantly larger and
TEXT_BASE is adjusted accordingly. U-Boot can be built for this
module with "$ make TQM8548_BE_config".
Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>

The TQM8548_AG module does not have the standard PCI/PCI-X interface
connected but just the PCI Express interface . So far it was not
possible to disable it without disabling the complete PCI interface
(CONFIG_PCI) including PCI Express.
Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>

As the reset vector is located at 0xfffffffc, all flash sectors from the
beginning of the U-Boot binary to 0xffffffff must be protected. On the
TQM8548-AG having small sectors at the end of the flash it happened that
the last two sector were not protected and an "erase all" left an
un-bootable system behind:

Bank # 2: CFI conformant FLASH (32 x 16)  Size: 32 MB in 270 Sectors
  AMD Standard command set, Manufacturer ID: 0xEC, Device ID: 0x257E
  Erase timeout: 8192 ms, write timeout: 1 ms

  FFFA0000 E RO   FFFC0000   RO   FFFE0000   RO   FFFE4000   RO   FFFE8000   RO
  FFFEC000   RO   FFFF0000   RO   FFFF4000   RO   FFFF8000 E      FFFFC000

The same bug seems to be in drivers/mtd/cfi_flash.c:flash_init() and many
board BSPs as well.
Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>

- Update style of 86xx CPU information on boot to more closely
  match 85xx boards
- Fix detection of 8641/8641D
- Use strmhz() to display frequencies
- Display L1 information
- Display L2 cache size
- Fixed CPU/SVR version output

== Before ==
Freescale PowerPC
CPU:
    Core: E600 Core 0, Version: 0.2, (0x80040202)
    System: Unknown, Version: 2.1, (0x80900121)
    Clocks: CPU:1066 MHz, MPX: 533 MHz, DDR: 266 MHz, LBC: 133 MHz
    L2: Enabled
Board: X-ES XPedite5170 3U VPX SBC

== After ==
CPU:   8641D, Version: 2.1, (0x80900121)
Core:  E600 Core 0, Version: 2.2, (0x80040202)
Clock Configuration:
       CPU:1066.667 MHz, MPX:533.333 MHz
       DDR:266.667 MHz (533.333 MT/s data rate), LBC:133.333 MHz
L1:    D-cache 32 KB enabled
       I-cache 32 KB enabled
L2:    512 KB enabled
Board: X-ES XPedite5170 3U VPX SBC
Signed-off-by: NPeter Tyser <ptyser@xes-inc.com>

Signed-off-by: NPeter Tyser <ptyser@xes-inc.com>

Update the 86xx reset sequence to try executing a board-specific reset
function.  If the board-specific reset is not implemented or does not
succeed, then assert #HRESET_REQ.  Using #HRESET_REQ is a more standard
reset procedure than the previous method and allows all board
peripherals to be reset if needed.
Signed-off-by: NPeter Tyser <ptyser@xes-inc.com>

Previously if we >=4G of memory and !CONFIG_PHYS_64BIT we'd report
an error and hang.  Instead of doing that since DDR is mapped in the
lowest priority LAWs we setup the DDR controller and the max amount
of memory we report back is what we can map (CONFIG_MAX_MEM_MAPPED)
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Acked-by: NBecky Bruce <beckyb@kernel.crashing.org>

Added various p2020 processor specific details:
* SVR for p2020, p2020E
* immap updates for LAWs and DDR on p2020
* LAW defines related to p2020
Signed-off-by: NSrikanth Srinivasan <srikanth.srinivasan@freescale.com>
Signed-off-by: NTravis Wheatley <Travis.Wheatley@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Added some info that is printed out when we boot to distiquish if we
built MPC8572DS_config vs MPC8572DS_36BIT_config since they have
different address maps.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The device tree's PHY addresses need to be fixed up if we're using the
SGMII Riser Card.

The 8572, 8536, and 8544 DS boards were modified to call this function.

Code idea taken from Liu Yu <yu.liu@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

Signed-off-by: NAndy Fleming <afleming@freescale.com>

This allows code to iterate through the ethernet devices
Signed-off-by: NAndy Fleming <afleming@freescale.com>

In the 36-bit physical config for MPC8572DS when need the start address
of memory and it size to be kept in phys_*_t instead of a ulong since
we support >4G of memory in the config and ulong cant represent that.
Otherwise we end up seeing the memory node in the device tree reporting
back we have memory starting @ 0 and of size 0.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

When we introduced the 36-bit config of the MPC8572DS board we had the
wrong PCI MEM bus address map.  Additionally, the change to the address
map exposes a small issue in our dummy read on the ULI bus.  We need
to use the new mapping functions to handle that read properly in the
36-bit config.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Previously we only allowed power-of-two memory sizes and didnt
handle >2G of memory.  Now we will map up to CONFIG_MAX_MEM_MAPPED
and should properly handle any size that we can make in the TLBs
we have available to us
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

If we only have one controller we can completely ignore how
memctl_intlv_ctl is set.  Otherwise other levels of code get confused
and think we have twice as much memory.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Only print 4 cpu freq per line.  This way when we have 8 cores its a
bit more readable.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>