|  | 
 | 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 |