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