1 files changed, 46 insertions, 0 deletions
diff --git a/qemu/roms/u-boot/doc/I2C_Edge_Conditions b/qemu/roms/u-boot/doc/I2C_Edge_Conditions
new file mode 100644
index 000000000..f4a996870
--- /dev/null
+++ b/qemu/roms/u-boot/doc/I2C_Edge_Conditions
@@ -0,0 +1,46 @@
+I2C Edge Conditions:
+====================
+
+    I2C devices may be left in a write state if a read was occuring
+    and the CPU was reset. This may result in EEPROM data corruption.
+
+    The edge condition is as follows:
+	1) A read operation begins.
+	2) I2C controller issues a start command.
+	3) The I2C writes the device address.
+	4) The CPU is reset at this point.
+
+    Once the CPU reinitializes and the read is tried again:
+	1) The I2C controller issues a start command.
+	2) The I2C controller writes the device address.
+	3) The I2C controller writes the offset.
+
+    The EEPROM sees:
+	1) START
+	2) device address
+	3) START "this start is ignored by most EEPROMs"
+	4) device address "EEPROM interprets this as offset"
+	5) Offset in device, "EEPROM interprets this as data to write"
+
+    The device will interpret this sequence as a WRITE command and
+    write rubbish into itself, i.e. the "offset" will be interpreted
+    as data to be written in location "device address".
+
+Notes
+-----
+!!!THIS IS AN UNDOCUMENTED I2C BUS BUG, NOT A AMCC 4xx BUG!!!
+
+This reset edge condition could possibly be present in every I2C
+controller and device available. For boards where a I2C bus reset
+function can be implemented a i2c_init_board() function should be
+provided and enabled by #define'ing CONFIG_SYS_I2C_INIT_BOARD in your
+board's config file. Note that this is NOT necessary when using the
+bit-banging I2C driver (common/soft_i2c.c) as this already includes
+the I2C bus reset sequence.
+
+
+Many thanks to Bill Hunter for finding this serious BUG.
+email to: <williamhunter@attbi.com>
+
+Erik Theisen <etheisen@mindspring.com>
+Tue, 5 Mar 2002 23:02:19 -0500 (Wed 05:02 MET)