karo: tx51: remove duplicate CONFIG_SYS_SDRAM_CLK definition

[karo-tx-uboot.git] / README

diff --git a/README b/README
index e2ca76e7aedd6cb721bd4540e91e5cf9da0f6971..06c09c5c478e3b33ff7f3b30b1e6b2954787140a 100644 (file)
--- a/README
+++ b/README
@@ -1,24 +1,8 @@
 #
-# (C) Copyright 2000 - 2012
+# (C) Copyright 2000 - 2013
 # Wolfgang Denk, DENX Software Engineering, wd@denx.de.
 #
-# See file CREDITS for list of people who contributed to this
-# project.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License as
-# published by the Free Software Foundation; either version 2 of
-# the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
-# MA 02111-1307 USA
+# SPDX-License-Identifier:     GPL-2.0+
 #
 
 Summary:
@@ -1820,6 +1804,17 @@ CBFS (Coreboot Filesystem) support
                4th and following
                BOOTP requests:         delay 0 ... 8 sec
 
+- BOOTP Random transaction ID:
+               CONFIG_BOOTP_RANDOM_ID
+
+               The standard algorithm to generate a DHCP/BOOTP transaction ID
+               by using the MAC address and the current time stamp may not
+               quite unlikely produce duplicate transaction IDs from different
+               clients in the same network. This option creates a transaction
+               ID using the rand() function. Provided that the RNG has been
+               seeded well, this should guarantee unique transaction IDs
+               always.
+
 - DHCP Advanced Options:
                You can fine tune the DHCP functionality by defining
                CONFIG_BOOTP_* symbols:
@@ -1968,6 +1963,28 @@ CBFS (Coreboot Filesystem) support
                    CONFIG_SYS_I2C_SOFT_SPEED_4 and CONFIG_SYS_I2C_SOFT_SLAVE_4
                    for defining speed and slave address
 
+               - drivers/i2c/fsl_i2c.c:
+                 - activate i2c driver with CONFIG_SYS_I2C_FSL
+                   define CONFIG_SYS_FSL_I2C_OFFSET for setting the register
+                   offset CONFIG_SYS_FSL_I2C_SPEED for the i2c speed and
+                   CONFIG_SYS_FSL_I2C_SLAVE for the slave addr of the first
+                   bus.
+                  - If your board supports a second fsl i2c bus, define
+                   CONFIG_SYS_FSL_I2C2_OFFSET for the register offset
+                   CONFIG_SYS_FSL_I2C2_SPEED for the speed and
+                   CONFIG_SYS_FSL_I2C2_SLAVE for the slave address of the
+                   second bus.
+
+               - drivers/i2c/tegra_i2c.c:
+                - activate this driver with CONFIG_SYS_I2C_TEGRA
+                - This driver adds 4 i2c buses with a fix speed from
+                  100000 and the slave addr 0!
+
+               - drivers/i2c/ppc4xx_i2c.c
+                 - activate this driver with CONFIG_SYS_I2C_PPC4XX
+                 - CONFIG_SYS_I2C_PPC4XX_CH0 activate hardware channel 0
+                 - CONFIG_SYS_I2C_PPC4XX_CH1 activate hardware channel 1
+
                additional defines:
 
                CONFIG_SYS_NUM_I2C_BUSES
@@ -2213,58 +2230,6 @@ CBFS (Coreboot Filesystem) support
                If not defined, then U-Boot uses predefined value for
                specified DTT device.
 
-               CONFIG_FSL_I2C
-
-               Define this option if you want to use Freescale's I2C driver in
-               drivers/i2c/fsl_i2c.c.
-
-               CONFIG_I2C_MUX
-
-               Define this option if you have I2C devices reached over 1 .. n
-               I2C Muxes like the pca9544a. This option addes a new I2C
-               Command "i2c bus [muxtype:muxaddr:muxchannel]" which adds a
-               new I2C Bus to the existing I2C Busses. If you select the
-               new Bus with "i2c dev", u-bbot sends first the commandos for
-               the muxes to activate this new "bus".
-
-               CONFIG_I2C_MULTI_BUS must be also defined, to use this
-               feature!
-
-               Example:
-               Adding a new I2C Bus reached over 2 pca9544a muxes
-                       The First mux with address 70 and channel 6
-                       The Second mux with address 71 and channel 4
-
-               => i2c bus pca9544a:70:6:pca9544a:71:4
-
-               Use the "i2c bus" command without parameter, to get a list
-               of I2C Busses with muxes:
-
-               => i2c bus
-               Busses reached over muxes:
-               Bus ID: 2
-                 reached over Mux(es):
-                   pca9544a@70 ch: 4
-               Bus ID: 3
-                 reached over Mux(es):
-                   pca9544a@70 ch: 6
-                   pca9544a@71 ch: 4
-               =>
-
-               If you now switch to the new I2C Bus 3 with "i2c dev 3"
-               u-boot first sends the command to the mux@70 to enable
-               channel 6, and then the command to the mux@71 to enable
-               the channel 4.
-
-               After that, you can use the "normal" i2c commands as
-               usual to communicate with your I2C devices behind
-               the 2 muxes.
-
-               This option is actually implemented for the bitbanging
-               algorithm in common/soft_i2c.c and for the Hardware I2C
-               Bus on the MPC8260. But it should be not so difficult
-               to add this option to other architectures.
-
                CONFIG_SOFT_I2C_READ_REPEATED_START
 
                defining this will force the i2c_read() function in