[Please keep this discussion on the mailing list so it gets archived and others can benefit from it, too.]
In message 36446.202.62.67.130.1116316510.squirrel@202.62.67.130 you wrote:
Suppose if any currepted image exists in server,u-boot downloads this currepted file into embedded system flash.
If it's a corruption that happened on the way of copying and transferring images, then the CRC32 checksum mechanism can be used to prevent you from storing corrupted images in the flash at all. Just use the "imi" command before storing the image to flash, somthing like
tftp ... && imi && cp.b ...
[assuming you have the hish shell enabled, which you should have for such purposes.]
Once we reset the embdded system kernel may not comeup. To overcome this we have made some changes to u-boot to get images from externel server when it finds kernel is not OK. But this is contineous loop .
There is no need for this. U-Boot supports a boot counter which can be used to break out of tsuch a loop. It was implemented EXACTLY for this purpose. See the "bootcnt", "bootlimit" and "altbootcmd" environment variables.
With this we can solve problem, but we may complete FALSH write cycles(if it works contineously for day/two).
Don't do it, then ;-)
It it does not get, then it should send a log message to external system(where the syslog server is running).so that user can see the message and plase the correct iamge in tftp server.
You can use simple console redirection in U-Boot for this purpose. We support console over network.
Summarizing: there is no need to implement anything at all: all features you might need are already in place. The only exception is that the CPU dependent part of the bootcount feature is not available on all processors yet, but it is trivial to implement.
Best regards,
Wolfgang Denk