README

		Enables FPGA subsystem.

		CONFIG_FPGA_<vendor>

		Enables support for specific chip vendors.
		(ALTERA, XILINX)

		CONFIG_FPGA_<family>

		Enables support for FPGA family.
		(SPARTAN2, SPARTAN3, VIRTEX2, CYCLONE2, ACEX1K, ACEX)

		CONFIG_SYS_FPGA_CHECK_BUSY

		Enable checks on FPGA configuration interface busy
		status by the configuration function. This option
		will require a board or device specific function to
		be written.

		CFG_FPGA_DELAY

		If defined, a function that provides delays in the FPGA
		configuration driver.

		CONFIG_SYS_FPGA_CHECK_ERROR

		Check for configuration errors during FPGA bitfile
		loading. For example, abort during Virtex II
		configuration if the INIT_B line goes low (which
		indicated a CRC error).

		CFG_SYS_FPGA_WAIT_INIT

		Maximum time to wait for the INIT_B line to de-assert
		after PROB_B has been de-asserted during a Virtex II
		FPGA configuration sequence. The default time is 500
		ms.

		CFG_SYS_FPGA_WAIT_BUSY

		Maximum time to wait for BUSY to de-assert during
		Virtex II FPGA configuration. The default is 5 ms.

		CFG_SYS_FPGA_WAIT_CONFIG

		Time to wait after FPGA configuration. The default is
		200 ms.

- Vendor Parameter Protection:

		U-Boot considers the values of the environment
		variables "serial#" (Board Serial Number) and
		"ethaddr" (Ethernet Address) to be parameters that
		are set once by the board vendor / manufacturer, and
		protects these variables from casual modification by
		the user. Once set, these variables are read-only,
		and write or delete attempts are rejected. You can
		change this behaviour:

		If CONFIG_ENV_OVERWRITE is #defined in your config
		file, the write protection for vendor parameters is
		completely disabled. Anybody can change or delete
		these parameters.

		The same can be accomplished in a more flexible way
		for any variable by configuring the type of access
		to allow for those variables in the ".flags" variable
		or define CFG_ENV_FLAGS_LIST_STATIC.

- Protected RAM:
		CFG_PRAM

		Define this variable to enable the reservation of
		"protected RAM", i. e. RAM which is not overwritten
		by U-Boot. Define CFG_PRAM to hold the number of
		kB you want to reserve for pRAM. You can overwrite
		this default value by defining an environment
		variable "pram" to the number of kB you want to
		reserve. Note that the board info structure will
		still show the full amount of RAM. If pRAM is
		reserved, a new environment variable "mem" will
		automatically be defined to hold the amount of
		remaining RAM in a form that can be passed as boot
		argument to Linux, for instance like that:

			setenv bootargs ... mem=\${mem}
			saveenv

		This way you can tell Linux not to use this memory,
		either, which results in a memory region that will
		not be affected by reboots.

		*WARNING* If your board configuration uses automatic
		detection of the RAM size, you must make sure that
		this memory test is non-destructive. So far, the
		following board configurations are known to be
		"pRAM-clean":

			IVMS8, IVML24, SPD8xx,
			HERMES, IP860, RPXlite, LWMON,
			FLAGADM

- Error Recovery:
	Note:

		In the current implementation, the local variables
		space and global environment variables space are
		separated. Local variables are those you define by
		simply typing `name=value'. To access a local
		variable later on, you have write `$name' or
		`${name}'; to execute the contents of a variable
		directly type `$name' at the command prompt.

		Global environment variables are those you use
		setenv/printenv to work with. To run a command stored
		in such a variable, you need to use the run command,
		and you must not use the '$' sign to access them.

		To store commands and special characters in a
		variable, please use double quotation marks
		surrounding the whole text of the variable, instead
		of the backslashes before semicolons and special
		symbols.

- Default Environment:
		CFG_EXTRA_ENV_SETTINGS

		Define this to contain any number of null terminated
		strings (variable = value pairs) that will be part of
		the default environment compiled into the boot image.

		For example, place something like this in your
		board's config file:

		#define CFG_EXTRA_ENV_SETTINGS \
			"myvar1=value1\0" \
			"myvar2=value2\0"

		Warning: This method is based on knowledge about the
		internal format how the environment is stored by the
		U-Boot code. This is NOT an official, exported
		interface! Although it is unlikely that this format
		will change soon, there is no guarantee either.
		You better know what you are doing here.

		Note: overly (ab)use of the default environment is
		discouraged. Make sure to check other ways to preset
		the environment like the "source" command or the
		boot command first.

		CONFIG_DELAY_ENVIRONMENT

		Normally the environment is loaded when the board is
		initialised so that it is available to U-Boot. This inhibits
		that so that the environment is not available until
		explicitly loaded later by U-Boot code. With CONFIG_OF_CONTROL
		this is instead controlled by the value of
		/config/load-environment.

- Automatic software updates via TFTP server
		CONFIG_UPDATE_TFTP
		CONFIG_UPDATE_TFTP_CNT_MAX
		CONFIG_UPDATE_TFTP_MSEC_MAX

		These options enable and control the auto-update feature;
		for a more detailed description refer to doc/README.update.

- MTD Support (mtdparts command, UBI support)
		CONFIG_MTD_UBI_WL_THRESHOLD
		This parameter defines the maximum difference between the highest
		erase counter value and the lowest erase counter value of eraseblocks
		of UBI devices. When this threshold is exceeded, UBI starts performing
		wear leveling by means of moving data from eraseblock with low erase
		counter to eraseblocks with high erase counter.

		The default value should be OK for SLC NAND flashes, NOR flashes and
		other flashes which have eraseblock life-cycle 100000 or more.
		However, in case of MLC NAND flashes which typically have eraseblock
		life-cycle less than 10000, the threshold should be lessened (e.g.,
		to 128 or 256, although it does not have to be power of 2).

		default: 4096

		CONFIG_MTD_UBI_BEB_LIMIT
		This option specifies the maximum bad physical eraseblocks UBI
		expects on the MTD device (per 1024 eraseblocks). If the
		underlying flash does not admit of bad eraseblocks (e.g. NOR
		flash), this value is ignored.

		NAND datasheets often specify the minimum and maximum NVM
		(Number of Valid Blocks) for the flashes' endurance lifetime.
		The maximum expected bad eraseblocks per 1024 eraseblocks
		then can be calculated as "1024 * (1 - MinNVB / MaxNVB)",
		which gives 20 for most NANDs (MaxNVB is basically the total
		count of eraseblocks on the chip).

		To put it differently, if this value is 20, UBI will try to
		reserve about 1.9% of physical eraseblocks for bad blocks
		handling. And that will be 1.9% of eraseblocks on the entire
		NAND chip, not just the MTD partition UBI attaches. This means
		that if you have, say, a NAND flash chip admits maximum 40 bad
		eraseblocks, and it is split on two MTD partitions of the same
		size, UBI will reserve 40 eraseblocks when attaching a
		partition.

		default: 20

		CONFIG_MTD_UBI_FASTMAP
		Fastmap is a mechanism which allows attaching an UBI device
		in nearly constant time. Instead of scanning the whole MTD device it
		only has to locate a checkpoint (called fastmap) on the device.
		The on-flash fastmap contains all information needed to attach
		the device. Using fastmap makes only sense on large devices where
		attaching by scanning takes long. UBI will not automatically install
		a fastmap on old images, but you can set the UBI parameter
		CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT to 1 if you want so. Please note
		that fastmap-enabled images are still usable with UBI implementations
		without	fastmap support. On typical flash devices the whole fastmap
		fits into one PEB. UBI will reserve PEBs to hold two fastmaps.

		CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT
		Set this parameter to enable fastmap automatically on images
		without a fastmap.
		default: 0

		CONFIG_MTD_UBI_FM_DEBUG
		Enable UBI fastmap debug
		default: 0

- SPL framework
		CONFIG_SPL
		Enable building of SPL globally.

		CONFIG_SPL_PANIC_ON_RAW_IMAGE
		When defined, SPL will panic() if the image it has
		loaded does not have a signature.
		Defining this is useful when code which loads images
		in SPL cannot guarantee that absolutely all read errors
		will be caught.
		An example is the LPC32XX MLC NAND driver, which will
		consider that a completely unreadable NAND block is bad,
		and thus should be skipped silently.

		CONFIG_SPL_DISPLAY_PRINT
		For ARM, enable an optional function to print more information
		about the running system.

		CONFIG_SPL_MPC83XX_WAIT_FOR_NAND
		Set this for NAND SPL on PPC mpc83xx targets, so that
		start.S waits for the rest of the SPL to load before
		continuing (the hardware starts execution after just
		loading the first page rather than the full 4K).

		CONFIG_SPL_UBI
		Support for a lightweight UBI (fastmap) scanner and
		loader

		CONFIG_SYS_NAND_5_ADDR_CYCLE, CONFIG_SYS_NAND_PAGE_COUNT,
		CONFIG_SYS_NAND_PAGE_SIZE, CONFIG_SYS_NAND_OOBSIZE,
		CONFIG_SYS_NAND_BLOCK_SIZE, CONFIG_SYS_NAND_BAD_BLOCK_POS,
		CFG_SYS_NAND_ECCPOS, CFG_SYS_NAND_ECCSIZE,
		CFG_SYS_NAND_ECCBYTES
		Defines the size and behavior of the NAND that SPL uses
		to read U-Boot

		CFG_SYS_NAND_U_BOOT_DST
		Location in memory to load U-Boot to

		CFG_SYS_NAND_U_BOOT_SIZE
		Size of image to load

		CFG_SYS_NAND_U_BOOT_START
		Entry point in loaded image to jump to

		CONFIG_SPL_RAM_DEVICE
		Support for running image already present in ram, in SPL binary

		CONFIG_SPL_FIT_PRINT
		Printing information about a FIT image adds quite a bit of
		code to SPL. So this is normally disabled in SPL. Use this
		option to re-enable it. This will affect the output of the
		bootm command when booting a FIT image.

- Interrupt support (PPC):

		There are common interrupt_init() and timer_interrupt()
		for all PPC archs. interrupt_init() calls interrupt_init_cpu()
		for CPU specific initialization. interrupt_init_cpu()
		should set decrementer_count to appropriate value. If
		CPU resets decrementer automatically after interrupt
		(ppc4xx) it should set decrementer_count to zero.
		timer_interrupt() calls timer_interrupt_cpu() for CPU
		specific handling. If board has watchdog / status_led
		/ other_activity_monitor it works automatically from
		general timer_interrupt().


Board initialization settings:
------------------------------

During Initialization u-boot calls a number of board specific functions
to allow the preparation of board specific prerequisites, e.g. pin setup
before drivers are initialized. To enable these callbacks the
following configuration macros have to be defined. Currently this is
architecture specific, so please check arch/your_architecture/lib/board.c
typically in board_init_f() and board_init_r().

- CONFIG_BOARD_EARLY_INIT_F: Call board_early_init_f()
- CONFIG_BOARD_EARLY_INIT_R: Call board_early_init_r()
- CONFIG_BOARD_LATE_INIT: Call board_late_init()

Configuration Settings:
-----------------------

- MEM_SUPPORT_64BIT_DATA: Defined automatically if compiled as 64-bit.
		Optionally it can be defined to support 64-bit memory commands.

- CONFIG_SYS_LONGHELP: Defined when you want long help messages included;
		undefine this when you're short of memory.

- CONFIG_SYS_HELP_CMD_WIDTH: Defined when you want to override the default
		width of the commands listed in the 'help' command output.

- CONFIG_SYS_PROMPT:	This is what U-Boot prints on the console to
		prompt for user input.

- CFG_SYS_BAUDRATE_TABLE:
		List of legal baudrate settings for this board.

- CFG_SYS_MEM_RESERVE_SECURE
		Only implemented for ARMv8 for now.
		If defined, the size of CFG_SYS_MEM_RESERVE_SECURE memory
		is substracted from total RAM and won't be reported to OS.
		This memory can be used as secure memory. A variable
		gd->arch.secure_ram is used to track the location. In systems
		the RAM base is not zero, or RAM is divided into banks,
		this variable needs to be recalcuated to get the address.

- CFG_SYS_SDRAM_BASE:
		Physical start address of SDRAM. _Must_ be 0 here.

- CFG_SYS_FLASH_BASE:
		Physical start address of Flash memory.

- CONFIG_SYS_MALLOC_LEN:
		Size of DRAM reserved for malloc() use.

- CONFIG_SYS_MALLOC_F_LEN
		Size of the malloc() pool for use before relocation. If
		this is defined, then a very simple malloc() implementation
		will become available before relocation. The address is just
		below the global data, and the stack is moved down to make
		space.

		This feature allocates regions with increasing addresses
		within the region. calloc() is supported, but realloc()
		is not available. free() is supported but does nothing.
		The memory will be freed (or in fact just forgotten) when
		U-Boot relocates itself.

- CONFIG_SYS_MALLOC_SIMPLE
		Provides a simple and small malloc() and calloc() for those
		boards which do not use the full malloc in SPL (which is
		enabled with CONFIG_SYS_SPL_MALLOC).

- CFG_SYS_BOOTMAPSZ:
		Maximum size of memory mapped by the startup code of
		the Linux kernel; all data that must be processed by
		the Linux kernel (bd_info, boot arguments, FDT blob if
		used) must be put below this limit, unless "bootm_low"
		environment variable is defined and non-zero. In such case
		all data for the Linux kernel must be between "bootm_low"
		and "bootm_low" + CFG_SYS_BOOTMAPSZ.	 The environment
		variable "bootm_mapsize" will override the value of
		CFG_SYS_BOOTMAPSZ.  If CFG_SYS_BOOTMAPSZ is undefined,
		then the value in "bootm_size" will be used instead.

- CONFIG_SYS_BOOT_GET_CMDLINE:
		Enables allocating and saving kernel cmdline in space between
		"bootm_low" and "bootm_low" + BOOTMAPSZ.

- CONFIG_SYS_BOOT_GET_KBD:
		Enables allocating and saving a kernel copy of the bd_info in
		space between "bootm_low" and "bootm_low" + BOOTMAPSZ.

- CONFIG_SYS_FLASH_PROTECTION
		If defined, hardware flash sectors protection is used
		instead of U-Boot software protection.

- CONFIG_SYS_FLASH_CFI:
		Define if the flash driver uses extra elements in the
		common flash structure for storing flash geometry.

- CONFIG_FLASH_CFI_DRIVER
		This option also enables the building of the cfi_flash driver
		in the drivers directory

- CONFIG_FLASH_CFI_MTD
		This option enables the building of the cfi_mtd driver
		in the drivers directory. The driver exports CFI flash
		to the MTD layer.

- CONFIG_SYS_FLASH_USE_BUFFER_WRITE
		Use buffered writes to flash.

- CONFIG_ENV_FLAGS_LIST_DEFAULT
- CFG_ENV_FLAGS_LIST_STATIC
	Enable validation of the values given to environment variables when
	calling env set.  Variables can be restricted to only decimal,
	hexadecimal, or boolean.  If CONFIG_CMD_NET is also defined,
	the variables can also be restricted to IP address or MAC address.

	The format of the list is:
		type_attribute = [s|d|x|b|i|m]
		access_attribute = [a|r|o|c]
		attributes = type_attribute[access_attribute]
		entry = variable_name[:attributes]
		list = entry[,list]

	The type attributes are:
		s - String (default)
		d - Decimal
		x - Hexadecimal
		b - Boolean ([1yYtT|0nNfF])
		i - IP address
		m - MAC address

	The access attributes are:
		a - Any (default)
		r - Read-only
		o - Write-once
		c - Change-default

	- CONFIG_ENV_FLAGS_LIST_DEFAULT
		Define this to a list (string) to define the ".flags"
		environment variable in the default or embedded environment.

	- CFG_ENV_FLAGS_LIST_STATIC
		Define this to a list (string) to define validation that
		should be done if an entry is not found in the ".flags"
		environment variable.  To override a setting in the static
		list, simply add an entry for the same variable name to the
		".flags" variable.

	If CONFIG_REGEX is defined, the variable_name above is evaluated as a
	regular expression. This allows multiple variables to define the same
	flags without explicitly listing them for each variable.

The following definitions that deal with the placement and management
of environment data (variable area); in general, we support the
following configurations:

BE CAREFUL! The first access to the environment happens quite early
in U-Boot initialization (when we try to get the setting of for the
console baudrate). You *MUST* have mapped your NVRAM area then, or
U-Boot will hang.

Please note that even with NVRAM we still use a copy of the
environment in RAM: we could work on NVRAM directly, but we want to
keep settings there always unmodified except somebody uses "saveenv"
to save the current settings.

BE CAREFUL! For some special cases, the local device can not use
"saveenv" command. For example, the local device will get the
environment stored in a remote NOR flash by SRIO or PCIE link,
but it can not erase, write this NOR flash by SRIO or PCIE interface.

- CONFIG_NAND_ENV_DST

	Defines address in RAM to which the nand_spl code should copy the
	environment. If redundant environment is used, it will be copied to
	CONFIG_NAND_ENV_DST + CONFIG_ENV_SIZE.

Please note that the environment is read-only until the monitor
has been relocated to RAM and a RAM copy of the environment has been
created; also, when using EEPROM you will have to use env_get_f()
until then to read environment variables.

The environment is protected by a CRC32 checksum. Before the monitor
is relocated into RAM, as a result of a bad CRC you will be working
with the compiled-in default environment - *silently*!!! [This is
necessary, because the first environment variable we need is the
"baudrate" setting for the console - if we have a bad CRC, we don't
have any device yet where we could complain.]

Note: once the monitor has been relocated, then it will complain if
the default environment is used; a new CRC is computed as soon as you
use the "saveenv" command to store a valid environment.

- CONFIG_SYS_FAULT_MII_ADDR:
		MII address of the PHY to check for the Ethernet link state.

- CONFIG_DISPLAY_BOARDINFO
		Display information about the board that U-Boot is running on
		when U-Boot starts up. The board function checkboard() is called
		to do this.

- CONFIG_DISPLAY_BOARDINFO_LATE
		Similar to the previous option, but display this information
		later, once stdio is running and output goes to the LCD, if
		present.

Low Level (hardware related) configuration options:
---------------------------------------------------

- CONFIG_SYS_CACHELINE_SIZE:
		Cache Line Size of the CPU.

- CONFIG_SYS_CCSRBAR_DEFAULT:
		Default (power-on reset) physical address of CCSR on Freescale
		PowerPC SOCs.

- CFG_SYS_CCSRBAR:
		Virtual address of CCSR.  On a 32-bit build, this is typically
		the same value as CONFIG_SYS_CCSRBAR_DEFAULT.

- CFG_SYS_CCSRBAR_PHYS:
		Physical address of CCSR.  CCSR can be relocated to a new
		physical address, if desired.  In this case, this macro should
		be set to that address.	 Otherwise, it should be set to the
		same value as CONFIG_SYS_CCSRBAR_DEFAULT.  For example, CCSR
		is typically relocated on 36-bit builds.  It is recommended
		that this macro be defined via the _HIGH and _LOW macros:

		#define CFG_SYS_CCSRBAR_PHYS ((CFG_SYS_CCSRBAR_PHYS_HIGH
			* 1ull) << 32 | CFG_SYS_CCSRBAR_PHYS_LOW)

- CFG_SYS_CCSRBAR_PHYS_HIGH:
		Bits 33-36 of CFG_SYS_CCSRBAR_PHYS.	This value is typically
		either 0 (32-bit build) or 0xF (36-bit build).	This macro is
		used in assembly code, so it must not contain typecasts or
		integer size suffixes (e.g. "ULL").

- CFG_SYS_CCSRBAR_PHYS_LOW:
		Lower 32-bits of CFG_SYS_CCSRBAR_PHYS.  This macro is
		used in assembly code, so it must not contain typecasts or
		integer size suffixes (e.g. "ULL").

- CONFIG_SYS_IMMR:	Physical address of the Internal Memory.
		DO NOT CHANGE unless you know exactly what you're
		doing! (11-4) [MPC8xx systems only]

- CFG_SYS_INIT_RAM_ADDR:

		Start address of memory area that can be used for
		initial data and stack; please note that this must be
		writable memory that is working WITHOUT special
		initialization, i. e. you CANNOT use normal RAM which
		will become available only after programming the
		memory controller and running certain initialization
		sequences.

		U-Boot uses the following memory types:
		- MPC8xx: IMMR (internal memory of the CPU)

- CONFIG_SYS_SCCR:	System Clock and reset Control Register (15-27)

- CONFIG_SYS_OR_TIMING_SDRAM:
		SDRAM timing

- CONFIG_SYS_SRIOn_MEM_VIRT:
		Virtual Address of SRIO port 'n' memory region

- CONFIG_SYS_SRIOn_MEM_PHYxS:
		Physical Address of SRIO port 'n' memory region

- CONFIG_SYS_SRIOn_MEM_SIZE:
		Size of SRIO port 'n' memory region

- CONFIG_SYS_NAND_BUSWIDTH_16BIT
		Defined to tell the NAND controller that the NAND chip is using
		a 16 bit bus.
		Not all NAND drivers use this symbol.
		Example of drivers that use it:
		- drivers/mtd/nand/raw/ndfc.c
		- drivers/mtd/nand/raw/mxc_nand.c

- CONFIG_SYS_NDFC_EBC0_CFG
		Sets the EBC0_CFG register for the NDFC. If not defined
		a default value will be used.

- CONFIG_SYS_SPD_BUS_NUM
		If SPD EEPROM is on an I2C bus other than the first
		one, specify here. Note that the value must resolve
		to something your driver can deal with.

- CONFIG_FSL_DDR_INTERACTIVE
		Enable interactive DDR debugging. See doc/README.fsl-ddr.

- CONFIG_FSL_DDR_SYNC_REFRESH
		Enable sync of refresh for multiple controllers.

- CONFIG_FSL_DDR_BIST
		Enable built-in memory test for Freescale DDR controllers.

- CONFIG_RMII
		Enable RMII mode for all FECs.
		Note that this is a global option, we can't
		have one FEC in standard MII mode and another in RMII mode.

- CONFIG_CRC32_VERIFY
		Add a verify option to the crc32 command.
		The syntax is:

		=> crc32 -v <address> <count> <crc32>

		Where address/count indicate a memory area
		and crc32 is the correct crc32 which the
		area should have.

- CONFIG_LOOPW
		Add the "loopw" memory command. This only takes effect if
		the memory commands are activated globally (CONFIG_CMD_MEMORY).

- CONFIG_CMD_MX_CYCLIC
		Add the "mdc" and "mwc" memory commands. These are cyclic
		"md/mw" commands.
		Examples:

		=> mdc.b 10 4 500
		This command will print 4 bytes (10,11,12,13) each 500 ms.

		=> mwc.l 100 12345678 10
		This command will write 12345678 to address 100 all 10 ms.

		This only takes effect if the memory commands are activated
		globally (CONFIG_CMD_MEMORY).

- CONFIG_SPL_BUILD
		Set when the currently-running compilation is for an artifact
		that will end up in the SPL (as opposed to the TPL or U-Boot
		proper). Code that needs stage-specific behavior should check
		this.

- CONFIG_TPL_BUILD
		Set when the currently-running compilation is for an artifact
		that will end up in the TPL (as opposed to the SPL or U-Boot
		proper). Code that needs stage-specific behavior should check
		this.

- CONFIG_ARCH_MAP_SYSMEM
		Generally U-Boot (and in particular the md command) uses
		effective address. It is therefore not necessary to regard
		U-Boot address as virtual addresses that need to be translated
		to physical addresses. However, sandbox requires this, since
		it maintains its own little RAM buffer which contains all
		addressable memory. This option causes some memory accesses
		to be mapped through map_sysmem() / unmap_sysmem().

- CONFIG_X86_RESET_VECTOR
		If defined, the x86 reset vector code is included. This is not
		needed when U-Boot is running from Coreboot.

Freescale QE/FMAN Firmware Support:
-----------------------------------

The Freescale QUICCEngine (QE) and Frame Manager (FMAN) both support the
loading of "firmware", which is encoded in the QE firmware binary format.
This firmware often needs to be loaded during U-Boot booting, so macros
are used to identify the storage device (NOR flash, SPI, etc) and the address
within that device.

- CONFIG_SYS_FMAN_FW_ADDR
	The address in the storage device where the FMAN microcode is located.  The
	meaning of this address depends on which CONFIG_SYS_QE_FMAN_FW_IN_xxx macro
	is also specified.

- CONFIG_SYS_QE_FW_ADDR
	The address in the storage device where the QE microcode is located.  The
	meaning of this address depends on which CONFIG_SYS_QE_FMAN_FW_IN_xxx macro
	is also specified.

- CONFIG_SYS_QE_FMAN_FW_LENGTH
	The maximum possible size of the firmware.  The firmware binary format
	has a field that specifies the actual size of the firmware, but it
	might not be possible to read any part of the firmware unless some
	local storage is allocated to hold the entire firmware first.

- CONFIG_SYS_QE_FMAN_FW_IN_NOR
	Specifies that QE/FMAN firmware is located in NOR flash, mapped as
	normal addressable memory via the LBC.  CONFIG_SYS_FMAN_FW_ADDR is the
	virtual address in NOR flash.

- CONFIG_SYS_QE_FMAN_FW_IN_NAND
	Specifies that QE/FMAN firmware is located in NAND flash.
	CONFIG_SYS_FMAN_FW_ADDR is the offset within NAND flash.

- CONFIG_SYS_QE_FMAN_FW_IN_MMC
	Specifies that QE/FMAN firmware is located on the primary SD/MMC
	device.  CONFIG_SYS_FMAN_FW_ADDR is the byte offset on that device.

- CONFIG_SYS_QE_FMAN_FW_IN_REMOTE
	Specifies that QE/FMAN firmware is located in the remote (master)
	memory space.	CONFIG_SYS_FMAN_FW_ADDR is a virtual address which
	can be mapped from slave TLB->slave LAW->slave SRIO or PCIE outbound
	window->master inbound window->master LAW->the ucode address in
	master's memory space.

Freescale Layerscape Management Complex Firmware Support:
---------------------------------------------------------
The Freescale Layerscape Management Complex (MC) supports the loading of
"firmware".
This firmware often needs to be loaded during U-Boot booting, so macros
are used to identify the storage device (NOR flash, SPI, etc) and the address
within that device.

- CONFIG_FSL_MC_ENET
	Enable the MC driver for Layerscape SoCs.

Freescale Layerscape Debug Server Support:
-------------------------------------------
The Freescale Layerscape Debug Server Support supports the loading of
"Debug Server firmware" and triggering SP boot-rom.
This firmware often needs to be loaded during U-Boot booting.

- CONFIG_SYS_MC_RSV_MEM_ALIGN
	Define alignment of reserved memory MC requires

Reproducible builds
-------------------

In order to achieve reproducible builds, timestamps used in the U-Boot build
process have to be set to a fixed value.

This is done using the SOURCE_DATE_EPOCH environment variable.
SOURCE_DATE_EPOCH is to be set on the build host's shell, not as a configuration
option for U-Boot or an environment variable in U-Boot.

SOURCE_DATE_EPOCH should be set to a number of seconds since the epoch, in UTC.

Building the Software:
======================

Building U-Boot has been tested in several native build environments
and in many different cross environments. Of course we cannot support
all possibly existing versions of cross development tools in all
(potentially obsolete) versions. In case of tool chain problems we
recommend to use the ELDK (see https://www.denx.de/wiki/DULG/ELDK)
which is extensively used to build and test U-Boot.

If you are not using a native environment, it is assumed that you
have GNU cross compiling tools available in your path. In this case,
you must set the environment variable CROSS_COMPILE in your shell.
Note that no changes to the Makefile or any other source files are
necessary. For example using the ELDK on a 4xx CPU, please enter:

	$ CROSS_COMPILE=ppc_4xx-
	$ export CROSS_COMPILE

U-Boot is intended to be simple to build. After installing the
sources you must configure U-Boot for one specific board type. This
is done by typing:

	make NAME_defconfig

where "NAME_defconfig" is the name of one of the existing configu-
rations; see configs/*_defconfig for supported names.

Note: for some boards special configuration names may exist; check if
      additional information is available from the board vendor; for
      instance, the TQM823L systems are available without (standard)
      or with LCD support. You can select such additional "features"
      when choosing the configuration, i. e.

      make TQM823L_defconfig
	- will configure for a plain TQM823L, i. e. no LCD support

      make TQM823L_LCD_defconfig
	- will configure for a TQM823L with U-Boot console on LCD

      etc.


Finally, type "make all", and you should get some working U-Boot
images ready for download to / installation on your system:

- "u-boot.bin" is a raw binary image
- "u-boot" is an image in ELF binary format
- "u-boot.srec" is in Motorola S-Record format

By default the build is performed locally and the objects are saved
in the source directory. One of the two methods can be used to change
this behavior and build U-Boot to some external directory:

1. Add O= to the make command line invocations:

	make O=/tmp/build distclean
	make O=/tmp/build NAME_defconfig
	make O=/tmp/build all

2. Set environment variable KBUILD_OUTPUT to point to the desired location:

	export KBUILD_OUTPUT=/tmp/build
	make distclean
	make NAME_defconfig
	make all

Note that the command line "O=" setting overrides the KBUILD_OUTPUT environment
variable.

User specific CPPFLAGS, AFLAGS and CFLAGS can be passed to the compiler by
setting the according environment variables KCPPFLAGS, KAFLAGS and KCFLAGS.
For example to treat all compiler warnings as errors:

	make KCFLAGS=-Werror

Please be aware that the Makefiles assume you are using GNU make, so
for instance on NetBSD you might need to use "gmake" instead of
native "make".


If the system board that you have is not listed, then you will need
to port U-Boot to your hardware platform. To do this, follow these
steps:

1.  Create a new directory to hold your board specific code. Add any
    files you need. In your board directory, you will need at least
    the "Makefile" and a "<board>.c".
2.  Create a new configuration file "include/configs/<board>.h" for
    your board.
3.  If you're porting U-Boot to a new CPU, then also create a new
    directory to hold your CPU specific code. Add any files you need.
4.  Run "make <board>_defconfig" with your new name.
5.  Type "make", and you should get a working "u-boot.srec" file
    to be installed on your target system.
6.  Debug and solve any problems that might arise.
    [Of course, this last step is much harder than it sounds.]


Testing of U-Boot Modifications, Ports to New Hardware, etc.:
==============================================================

If you have modified U-Boot sources (for instance added a new board
or support for new devices, a new CPU, etc.) you are expected to
provide feedback to the other developers. The feedback normally takes
the form of a "patch", i.e. a context diff against a certain (latest
official or latest in the git repository) version of U-Boot sources.

But before you submit such a patch, please verify that your modifi-
cation did not break existing code. At least make sure that *ALL* of
the supported boards compile WITHOUT ANY compiler warnings. To do so,
just run the buildman script (tools/buildman/buildman), which will
configure and build U-Boot for ALL supported system. Be warned, this
will take a while. Please see the buildman README, or run 'buildman -H'
for documentation.


See also "U-Boot Porting Guide" below.


Monitor Commands - Overview:
============================

go	- start application at address 'addr'
run	- run commands in an environment variable
bootm	- boot application image from memory
bootp	- boot image via network using BootP/TFTP protocol
bootz   - boot zImage from memory
tftpboot- boot image via network using TFTP protocol
	       and env variables "ipaddr" and "serverip"
	       (and eventually "gatewayip")
tftpput - upload a file via network using TFTP protocol
rarpboot- boot image via network using RARP/TFTP protocol
diskboot- boot from IDE devicebootd   - boot default, i.e., run 'bootcmd'
loads	- load S-Record file over serial line
loadb	- load binary file over serial line (kermit mode)
loadm   - load binary blob from source address to destination address
md	- memory display
mm	- memory modify (auto-incrementing)
nm	- memory modify (constant address)
mw	- memory write (fill)
ms	- memory search
cp	- memory copy
cmp	- memory compare
crc32	- checksum calculation
i2c	- I2C sub-system
sspi	- SPI utility commands
base	- print or set address offset
printenv- print environment variables
pwm	- control pwm channels
setenv	- set environment variables
saveenv - save environment variables to persistent storage
protect - enable or disable FLASH write protection
erase	- erase FLASH memory
flinfo	- print FLASH memory information
nand	- NAND memory operations (see doc/README.nand)
bdinfo	- print Board Info structure
iminfo	- print header information for application image
coninfo - print console devices and informations
ide	- IDE sub-system
loop	- infinite loop on address range
loopw	- infinite write loop on address range
mtest	- simple RAM test
icache	- enable or disable instruction cache
dcache	- enable or disable data cache
reset	- Perform RESET of the CPU
echo	- echo args to console
version - print monitor version
help	- print online help
?	- alias for 'help'


Monitor Commands - Detailed Description:
========================================

TODO.

For now: just type "help <command>".


Note for Redundant Ethernet Interfaces:
=======================================

Some boards come with redundant Ethernet interfaces; U-Boot supports
such configurations and is capable of automatic selection of a
"working" interface when needed. MAC assignment works as follows:

Network interfaces are numbered eth0, eth1, eth2, ... Corresponding
MAC addresses can be stored in the environment as "ethaddr" (=>eth0),
"eth1addr" (=>eth1), "eth2addr", ...

If the network interface stores some valid MAC address (for instance
in SROM), this is used as default address if there is NO correspon-
ding setting in the environment; if the corresponding environment
variable is set, this overrides the settings in the card; that means:

o If the SROM has a valid MAC address, and there is no address in the
  environment, the SROM's address is used.

o If there is no valid address in the SROM, and a definition in the
  environment exists, then the value from the environment variable is
  used.

o If both the SROM and the environment contain a MAC address, and
  both addresses are the same, this MAC address is used.

o If both the SROM and the environment contain a MAC address, and the
  addresses differ, the value from the environment is used and a
  warning is printed.

o If neither SROM nor the environment contain a MAC address, an error
  is raised. If CONFIG_NET_RANDOM_ETHADDR is defined, then in this case
  a random, locally-assigned MAC is used.

If Ethernet drivers implement the 'write_hwaddr' function, valid MAC addresses
will be programmed into hardware as part of the initialization process.	 This
may be skipped by setting the appropriate 'ethmacskip' environment variable.
The naming convention is as follows:
"ethmacskip" (=>eth0), "eth1macskip" (=>eth1) etc.

Image Formats:
==============

U-Boot is capable of booting (and performing other auxiliary operations on)
images in two formats:

New uImage format (FIT)
-----------------------

Flexible and powerful format based on Flattened Image Tree -- FIT (similar
to Flattened Device Tree). It allows the use of images with multiple
components (several kernels, ramdisks, etc.), with contents protected by
SHA1, MD5 or CRC32. More details are found in the doc/uImage.FIT directory.


Old uImage format
-----------------

Old image format is based on binary files which can be basically anything,
preceded by a special header; see the definitions in include/image.h for
details; basically, the header defines the following image properties:

* Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD,
  4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks,
  LynxOS, pSOS, QNX, RTEMS, INTEGRITY;
  Currently supported: Linux, NetBSD, VxWorks, QNX, RTEMS, INTEGRITY).
* Target CPU Architecture (Provisions for Alpha, ARM, Intel x86,
  IA64, MIPS, Nios II, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit;
  Currently supported: ARM, Intel x86, MIPS, Nios II, PowerPC).
* Compression Type (uncompressed, gzip, bzip2)
* Load Address
* Entry Point
* Image Name
* Image Timestamp

The header is marked by a special Magic Number, and both the header
and the data portions of the image are secured against corruption by
CRC32 checksums.


Linux Support:
==============

Although U-Boot should support any OS or standalone application
easily, the main focus has always been on Linux during the design of
U-Boot.

U-Boot includes many features that so far have been part of some
special "boot loader" code within the Linux kernel. Also, any