mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-11-14 00:47:26 +00:00
f6e2c0f3e3
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com> |
||
---|---|---|
.. | ||
config.mk | ||
flash.c | ||
incaip.c | ||
lowlevel_init.S | ||
Makefile | ||
README |
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