init commit via android 4.4 uboot

1 files changed, 57 insertions, 0 deletions

diff --git a/doc/README.INCA-IP b/doc/README.INCA-IP
new file mode 100755
index 0000000..1329152
--- /dev/null
+++ b/doc/README.INCA-IP
@@ -0,0 +1,57 @@
+
+Flash programming on the INCA-IP board is complicated because of the
+EBU swapping unit. A BDI2000 can be used for flash programming only
+if the EBU swapping unit is enabled; otherwise it will not detect the
+flash memory. But the EBU swapping unit is disadbled after reset, so
+if you program some code to flash with the swapping unit on, it will
+not be runnable with the swapping unit off.
+
+The consequence is that you have to write a pre-swapped image to
+flash using the BDI2000. A simple host-side tool "inca-swap-bytes" is
+provided in the "tools/" directory. Use it as follows:
+
+	bash$ ./inca-swap-bytes <u-boot.bin >u-boot.bin.swp
+
+Note that the current BDI config file _disables_ the EBU swapping
+unit for the flash bank 0. To enable it, (this is required for the
+BDI flash commands to work) uncomment the following line in the
+config file:
+
+	;WM32   0xb8000260      0x404161ff ; Swapping unit enabled
+
+and comment out
+
+	WM32    0xb8000260      0x004161ff ; Swapping unit disabled
+
+Alternatively, you can use "mm 0xb8000260 <value>" commands to
+enable/disable the swapping unit manually.
+
+Just for reference, here is the complete sequence of actions we took
+to install a U-Boot image into flash.
+
+    1. ./inca-swap-bytes <u-boot.bin >u-boot.bin.swp
+
+    2. From BDI:
+
+	mm 0xb8000260  0x404161ff
+	erase 0xb0000000
+	erase 0xb0010000
+	prog 0xb0000000 /tftpboot/INCA/u-boot.bin.swp bin
+	mm 0xb8000260 0x004161ff
+	go 0xb0000000
+
+
+Ethernet autonegotiation needs some time to complete. Instead of
+delaying the boot process in all cases, we just start the
+autonegotiation process when U-Boot comes up and that is all. Most
+likely, it will complete by the time the network transfer is
+attempted for the first time. In the worst case, if a transfer is
+attempted before the autonegotiation is complete, just a single
+packet would be lost resulting in a single timeout error, and then
+the transfer would proceed normally. So the time that we would have
+lost unconditionally waiting for the autonegotiation to complete, we
+have to wait only if the file transfer is started immediately after
+reset. We've verified that this works for all the clock
+configurations.
+
+(C) 2003 Wolfgang Denk