This patch consists of the following:
1. NAND Flash Controller (NFC) pin configuration.
2. NFC clock configuration (enable the clock, initialize the clock rate.)
3. Changes to the `fsl_nfc` NFC driver:
     * Code cleanup (there were compilation warnings, e.g. unused data
         and functions.)
     * `#include <asm/immap.h>` should not be used on ARM.
     * Disable the GPIO configuration code on ARM.
     * Use `__raw_writel/__raw_readl` instead of `out_be32/in_be32`.
         The registers of the NAND Flash Controller always use the
         same endianness as the MCU core.
     * Make the code in fsl_nfc_get_id() and fsl_nfc_get_status()
         endianness-independent (they were accessing the data from
         32-bit register as an array of u8, this approach is
         endianness-dependent.)
4. NAND support in the U-Boot configuration file.
5. Support for environment in the NAND flash in the U-Boot configuration
     file.
6. Increase the size of the `RAM` memory region to fit the statically
allocated data for the NAND driver and the U-Boot framework for NAND.

Import the existing NAND Flash Controller driver for MCF5441x from
http://repository.timesys.com/buildsources/u/u-boot/u-boot-2009.08/u-boot-2009.08-mfc5441x.patch

The NAND Flash Controllers on MCF5441x and Kinetis are compatible, we
will use this driver for Kinetis.

This is required for using the NAND Flash.

Since the generic U-Boot code requires more than 128 KB of RAM for the
Bad Block Table and we are not going to heavily modify the generic code,
we add optional support for the malloc() poll in the external memory in
order to have enough space for the Bad Block Table (the whole internal
SRAM is only 128 KB in size.) The CONFIG_SYS_MALLOC_EXT_BASE and the
CONFIG_SYS_MALLOC_EXT_LEN options control the base address and size of
the malloc() pool. If those preprocessor variables are not defined, use
the original code for determining the position of the malloc() pool in
memory.

This is a cosmetic change, no changes in behaviour.

We use the UART2 which is connected to the DB9 port on the TWR-SER
board.

This is necessary to provide the MAC address to the Linux Ethernet
driver.

Using that option, print correct processor info at start-up.

Tested by loading it onto STM32F2 and making sure that it shows the right
prompt and other cosmetic messages.

Take the DDR controller configuration (including memory timings) from
the Freescale's sample code package (KINETIS_120MHZ_SC.zip).

Move `struct kinetis_sim_regs` to
`include/asm-arm/arch-kinetis/kinetis.h`, because the SIM registers
have to be updated in order to properly configure the DDR controller for
the given external memory chip.

DDR works in the asynchronous mode.

Set the DDR clock to 150 MHz (using the PLL1).

For the board with external DDR memory, the DDR configuration code
should be enabled using the CONFIG_KINETIS_DDR configuration option in
the U-Boot configuration file.

The `board/freescale/twr-k70f120m/board.c` file was copied from
`board/freescale/twr-k60n512/board.c` without code changes, because the
Ethernet pin configuration is compatible on these two boards.

`cpu/arm_cortexm3/kinetis/clock.c` was updated to support the MCG
(Multipurpose Clock Generator) internal structure on K70 @ 120 MHz
which is different from the MCG on K60 @ 100 MHz.

The U-Boot configuration file (include/configs/twr-k70f120m.h) was
copied from the corresponding file for the TWR-K60N512 board and
customized for the TWR-K70F120M board:
    1. UART pins are different
    2. There is external RAM on the TWR-K70F120M board
    3. The in-MCU flash is 1 MB in size
    4. The clock configuration was updated (120 MHz core clock)
    5. The K70 MCU has 6 GPIO ports (instead of 5 ports on K60)

Self-upgrade is possible now:
	tftp 0x1fff5800 aspotashev/k60/u-boot.bin
	cptf 0 ${fileaddr} ${filesize} 1

Since there is no external RAM on the TWR-K60N512 board, we put
the new U-Boot image into SRAM. The address of the RAM_BUF region
(0x1fff5800 in the above example) can be checked in the `u-boot.map`
file.

The RAM_BUF region is currently 84 Kbytes in size. U-Boot images larger
than this size cannot be safely loaded.

Write the necessary data into flash by flash sectors (2 Kbytes).
Use the "Program Section" command to write a complete flash sector.

If only a part of the sector should be updated, firstly load the
existing data that should not be changed into the write buffer (flash
programming acceleration RAM), and then write from this buffer into the
flash sector.
This technique makes it possible to update even single bytes without
damaging other data in the same flash sector.

Before writing at the flash address 0x40C, a check is performed to make
sure the MCU will not switch to the secure state.

All functions that may be called from `envm_write()` are put into the
`.ramcode` section, because the internal flash is not a safe place
when self-upgrade is in progress.

Like in the FNET project, we disable Single Entry Buffer and Data Cache
via FMC registers. This must be a workaround for an errata.

Also add the code for:
1. Enabling the clock gate for the Ethernet module of the MCU,
2. Pin configuration for RMII.
3. Disabling the MPU (the Ethernet module will be unable to work with
     the SRAM otherwise.)

The pull-down resistor for the RXER pin is enabled, because this input
pin is not connected to the PHY on the TWR-K60N512 board by default.

The value for the RCR (Receive Control Register) was wrong in the
half-duplex mode.

The `mcf*` targets were not checked for clean build.

The `mcf*` targets were not checked for clean build.

Also in this commit:
1. `kinetis_periph_enable()` for enabling clocks on various MCU modules.
2. Minimal GPIO driver with the `kinetis_gpio_config()` function.

FIFOs are not implemented in this driver (they can be enables via the
PFIFO, TXWATER and RXWATER registers), because on K60 only UART0
has a more than single-dataword FIFO, and UART0 is not used on the
TWR-K60N512 board.

We use the UART3 on the TWR-K60N512 board which is connected to the DB-9
port on the TWR-SER board in the TWR-K60N512-KIT board set.

Core/system clock rate: 100 MHz
Peripheral clock rate:   50 MHz
FlexBus clock rate:      50 MHz
Flash clock rate:        25 MHz

The PLL takes the 50 MHz on-board external clock from the EXTAL pin and
feeds the MCGOUTCLK with a 100 MHz clock.

On the Kinetis MCU, we have to sequentally switch between 3 clocking
modes until we can enter the desired PEE mode (PLL Engaged External
mode).

The `KINETIS_MCG_C2_EREFS_MSK` and `KINETIS_MCG_C2_HGO_MSK` bits should
be cleared, otherwise the Ethernet module of the MCU cannot send nor
receive packets.

Testing:
    `udelay(1000)` works correctly (tested by blinking the green LED.)

If we do not disable the watchdog timer in a few MCU clocks after reset,
it will reset the MCU.

* The USB clock configuration code is disabled by default
* PLL1 will be configured only if the USB clock is enabled by defining
    the CONFIG_LPC178X_USB_DIV option in the board configuration file.

Stubs for twr-k60n512 port.

The `.kinetis_flash_conf` section is necessary to keep the MCU flash
unprotected and allow future flash programming.

This port does not work, because the Watchdog Timer is not unlocked and
the MCU is reset by WDT shortly after start-up.

WheN left in "addip", this results in the boards hangup, see #76050.

Hang-up scenario before this patch:
At the time `udelay()` is called, the current value in
    the SYSTICK timer (`systick->val`) may be very close to, but greater
    than the number of clocks left to tick (`clc`).
Since `systick->val` is greater than `clc`, we use the `while` loop from
    the `else` block. But this `while` loops only checks that `systick->val`
    is greater than `(tmp - clc)` which is a very small positive integer
    (because `tmp` is very close to `clc`.) The `while` loop will now
    terminate only if we manage to catch `systick->val` in a very thin
    range between 0 and `(tmp - clc)`. The comparison inside the `while`
    loop condition takes a considerable number of CPU clocks, that makes it
    hard to find `systick->val` between 0 and `(tmp - clc)`, we just step
    over this small range.

This bug manifested when erasing NOR flash on EA-LPC1788-32: the
`udelay(1)` call in `flash_status_check()` in `drivers/mtd/cfi_flash.c`
was hanging.

u-boot-lpc.bin.

For EA-LPC1788, the U-Boot image suitable for programming is u-boot-lpc.bin.
This is inconsistent with other supported targets, where the image is
u-boot.bin. This patch fixes this.

To avoid hang-up of the Ethernet block after Cortex-M3 software reset
(SYSRESET), we need to reset the Ethernet PHY immediately before
performing the SYSRESET.

All new code added in this patch should be in placed in `.ramcode`,
because we might want to do a software reset after self-upgrade.

Since we cannot use `printf()` in functions that may be called during
self-upgrade (`printf()` is too big for `.ramcode`), the
`lpc178x_phy_init()` function cannot be easily used in
`lpc178x_phy_final_reset()`. Because of this, we use a pre-set PHY
address (`CONFIG_LPC178X_ETH_PHY_ADDR`) instead of doing automatic
PHY discovery that is usually done in `lpc178x_phy_init()`.

If Ethernet is not enabled in the U-Boot configuration file, we do not
perform the PHY reset.
This leads to a minor bug: if you install U-Boot without Ethernet
support into your board and do a self-upgrade to another build of
U-Boot with Ethernet support, the Ethernet driver will hang in the
latter U-Boot unless you have done a full reset (by pushing the SW1
button) after self-upgrade.

Pass "mem=16M" parameter to the Linux kernel on the boards
`ea-lpc1788` and `stm3220g-eval`.

Put multiline `printf()` calls in curly braces.

We use IAP commands for writing into eNVM.

All code and pre-initialized data that are used during self-upgrade
are forced to reside in `.ramcode` and `.data` respectively.
Uninitialized data go into `.bss` automatically.

1. Fixed the algorithm for checking if the transmit buffers are full.
2. Removed unnecessary `udelay()` calls that were kept after copying the
	code from the LPCware's U-Boot port.
3. Increased the numbers of receive and transmit DMA buffers.