In message 20040723102408.GB11790@synertronixx3 you wrote:
I wonder if there is a solution possible to Protect the FLASH Chip from typos.
No. I will not accept any submissions of an AI machine for U-Boot.
I have physikal Ram at 0x8000000 to 0x8FFFFFF and FLASH from 0x10000000 to 0x10FFFFFF.
...
tftpboot should only put downloaded images to RAM.
Indeed this is what it does. At least in the default configuration, i. e. if you don't enable options like CFG_DIRECT_FLASH_TFTP which are unsafe and officially deprecated.
I had a customer recently who put 130.1.2.3 as the 1st argument to tftpboot and tftpboot tries to put the image to 0x130.
U-Boot follows Unix design here:
"UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn
I also do typos there and an 0x0 as 1st Argument destroys contents of Flash though it is protected!
Seems you have configured U-Boot like that. On systems for which I am responsible attempts to TFTP to flash will not do harm.
I think an linux kernel Image for example contains code sequences who unlock, erase and write flash succesfully.
This may be, but a TFTP download will write to increasing addresses, while the programming sequence must be written to certain addresses which are (1) not contiguous and (2) which must be written in a special sequence. I don't think that TFTP (or a copy) to a memory region can accidentally trigger a flash programming sequence, unless the code explicitely attemts to program the flash (like TFTP with CFG_DIRECT_FLASH_TFTP option aenabled, or the "cp" command with a target address in flash memory).
I want to implement a mechanism which implements out of an config option a area where tftpboot acts (0x800000 to 0x8FFFFFF) and gives an error message otherway.
Such a feature is definitely not necessary. Don't waste your time. Instead, go and check what's going wrong on your system.
Best regards,
Wolfgang Denk