From d04075478d378d9e15f3e1abfd14b0bd124077d4 Mon Sep 17 00:00:00 2001 From: Kevin Date: Sat, 15 Nov 2014 11:48:36 +0800 Subject: init commit via android 4.4 uboot --- doc/README.INCA-IP | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100755 doc/README.INCA-IP (limited to 'doc/README.INCA-IP') 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.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 " 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.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 -- cgit