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