Merge branch 'master' of git://www.denx.de/git/u-boot-imx
[karo-tx-uboot.git] / README
diff --git a/README b/README
index 5928495..517b0b4 100644 (file)
--- a/README
+++ b/README
@@ -1152,6 +1152,7 @@ The following options need to be configured:
                CONFIG_RTC_DS1307       - use Maxim, Inc. DS1307 RTC
                CONFIG_RTC_DS1337       - use Maxim, Inc. DS1337 RTC
                CONFIG_RTC_DS1338       - use Maxim, Inc. DS1338 RTC
+               CONFIG_RTC_DS1339       - use Maxim, Inc. DS1339 RTC
                CONFIG_RTC_DS164x       - use Dallas DS164x RTC
                CONFIG_RTC_ISL1208      - use Intersil ISL1208 RTC
                CONFIG_RTC_MAX6900      - use Maxim, Inc. MAX6900 RTC
@@ -2040,6 +2041,24 @@ CBFS (Coreboot Filesystem) support
                4th and following
                BOOTP requests:         delay 0 ... 8 sec
 
+               CONFIG_BOOTP_ID_CACHE_SIZE
+
+               BOOTP packets are uniquely identified using a 32-bit ID. The
+               server will copy the ID from client requests to responses and
+               U-Boot will use this to determine if it is the destination of
+               an incoming response. Some servers will check that addresses
+               aren't in use before handing them out (usually using an ARP
+               ping) and therefore take up to a few hundred milliseconds to
+               respond. Network congestion may also influence the time it
+               takes for a response to make it back to the client. If that
+               time is too long, U-Boot will retransmit requests. In order
+               to allow earlier responses to still be accepted after these
+               retransmissions, U-Boot's BOOTP client keeps a small cache of
+               IDs. The CONFIG_BOOTP_ID_CACHE_SIZE controls the size of this
+               cache. The default is to keep IDs for up to four outstanding
+               requests. Increasing this will allow U-Boot to accept offers
+               from a BOOTP client in networks with unusually high latency.
+
 - DHCP Advanced Options:
                You can fine tune the DHCP functionality by defining
                CONFIG_BOOTP_* symbols:
@@ -3334,6 +3353,9 @@ FIT uImage format:
                Adds the MTD partitioning infrastructure from the Linux
                kernel. Needed for UBI support.
 
+               CONFIG_MTD_NAND_VERIFY_WRITE
+               verify if the written data is correct reread.
+
 - UBI support
                CONFIG_CMD_UBI
 
@@ -3347,6 +3369,64 @@ FIT uImage format:
                Make the verbose messages from UBI stop printing.  This leaves
                warnings and errors enabled.
 
+
+               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
+
 - UBIFS support
                CONFIG_CMD_UBIFS
 
@@ -4385,6 +4465,11 @@ use the "saveenv" command to store a valid environment.
                later, once stdio is running and output goes to the LCD, if
                present.
 
+- CONFIG_BOARD_SIZE_LIMIT:
+               Maximum size of the U-Boot image. When defined, the
+               build system checks that the actual size does not
+               exceed it.
+
 Low Level (hardware related) configuration options:
 ---------------------------------------------------