It looks typo error.
Not CPU15, CP15(CoProcessor15)

Signed-off-by: yeongjun Kim <iam.yeongjunkim@gmail.com>

Booting a payload out of NAND FLASH from the SPL is a crux today, as
it requires hard partioned FLASH. Not a brilliant idea with the
reliability of todays NAND FLASH chips.

The upstream UBI + UBI fastmap implementation which is about to
brought to u-boot is too heavy weight for SPLs as it provides way more
functionality than needed for a SPL and does not even fit into the
restricted SPL areas which are loaded from the SoC boot ROM.

So this provides a fast and lightweight implementation of UBI scanning
and UBI fastmap attach. The scan and logical to physical block mapping
code is developed from scratch, while the fastmap implementation is
lifted from the linux kernel source and stripped down to fit the SPL
needs.

The text foot print on the board which I used for development is:

6854	0	0	6854	1abd
drivers/mtd/ubispl/built-in.o

Attaching a NAND chip with 4096 physical eraseblocks (4 blocks are
reserved for the SPL) takes:

In full scan mode:      1172ms
In fastmap mode:          95ms

The code requires quite some storage. The largest and unknown part of
it is the number of fastmap blocks to read. Therefor the data
structure is not put into the BSS. The code requires a pointer to free
memory handed in which is initialized by the UBI attach code itself.

See doc/README.ubispl for further information on how to use it.

This shares the ubi-media.h and crc32 implementation of drivers/mtd/ubi
There is no way to share the fastmap code, as UBISPL only utilizes the
slightly modified functions ubi_attach_fastmap() and ubi_scan_fastmap()
from the original kernel ubi fastmap implementation.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Acked-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

Signed-off-by: Tom Rini <trini@konsulko.com>

Conflicts:
	arch/arm/cpu/armv8/Makefile
	arch/arm/lib/bootm-fdt.c

    Fix a number of typos, including:

     * "compatble" -> "compatible"
     * "eanbeld" -> "enabled"
     * "envrionment" -> "environment"
     * "FTD" -> "FDT" (for "flattened device tree")
     * "ommitted" -> "omitted"
     * "overriden" -> "overridden"
     * "partiton" -> "partition"
     * "propogate" -> "propagate"
     * "resourse" -> "resource"
     * "rest in piece" -> "rest in peace"
     * "suport" -> "support"
     * "varible" -> "variable"

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>

Secure_ram variable was put in generic global data. But only ARMv8
uses this variable. Move it to ARM specific data structure.

Signed-off-by: York Sun <york.sun@nxp.com>

This option is now widely available, so remove the comment that it is only
available on ARM and sandbox.

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

The same information now exists in common/Kconfig.  Do not duplicate
documentation from the point of view of maintainability.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>

At present CONFIG_SKIP_LOWLEVEL_INIT prevents U-Boot from calling
lowlevel_init(). This means that the instruction cache is not enabled and
the board runs very slowly.

What is really needed in many cases is to skip the call to lowlevel_init()
but still perform CP15 init. Add an option to handle this.

Reviewed-by: Heiko Schocher <hs@denx.de>
Tested-on: smartweb, corvus, taurus, axm
Tested-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andreas Bießmann <andreas@biessmann.org>

Remove the warning from the Makefile, since boards that do not use generic
board will no longer build. Also update documentation.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andreas Bießmann <andreas@biessmann.org>

Introduce the (optional) eeprom print and eeprom update commands.

These commands are eeprom layout aware:
* The eeprom print command prints the contents of the eeprom in a human
  readable way (eeprom layout fields, and data formatted to be fit for human
  consumption).
* The eeprom update command allows user to update eeprom fields by specifying
  the field name, and providing the new data in a human readable format (same
  format as displayed by the eeprom print command).
* Both commands can either auto detect the layout, or be told which layout to
  use.

New CONFIG options:
CONFIG_CMD_EEPROM_LAYOUT - enables commands.
CONFIG_EEPROM_LAYOUT_HELP_STRING - tells user what layout names are supported

Feature API:
__weak int parse_layout_version(char *str)
	- override to provide your own layout name parsing
__weak void __eeprom_layout_assign(struct eeprom_layout *layout, int layout_version);
	- override to setup the layout metadata based on the version
__weak int eeprom_layout_detect(unsigned char *data)
	- override to provide your own algorithm for detecting layout version
eeprom_field.c
	- contains various printing and updating functions for common types of
	  eeprom fields. Can be used for defining custom layouts.

Cc: Heiko Schocher <hs@denx.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Tom Rini <trini@konsulko.com>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>