Dear Sagar Heroorkar,
In message AANLkTilwlzwHniDQAl1VDQascJzJkzmBnoSwMyw2BjGF@mail.gmail.com you wrote:
Is there any other way to make the u-boot redundant other than what i have sent in the email earliar.
I still fail to understand where your requirements are coming from, resp. which exact goal you are trying to achieve.
If it's all about reliability, you should consider never updating / replacing U-Boot at all, and then a single copy is all you need in most cases.
If you have really paranoid reliability requirements, you cannot do without adequate support from the hardware design. Tyically such systems come with two separate, identical banks of NOR flash that are attached through some switch logic to two different chip select signals. In addition, they need a hardware watchdog (I mean a real one, that starts automatically and that cannot be stopped by software), and logic that allows to detect the a watchdog reset.
Assume in "normal" position the switch connects flash bank 1 as boot device (say, chip select CS0), and flash bank 2 to another device (say, chip select 1).
You would then install the same copy of U-Boot into both flash banks 1 and 2.
Upon power-on, the watchdog starts running, and the system will boot from the image in flash bank 1. If it's working fine, it will trigger the watchdog, and everything is fine.
In case of errors (image corrupt, flash broken, ...) the watchdog will time out and cause a watchdog reset, which gets detected by the board logic. After a predetermined number of such watchdog resets (N=1 is of course also an option) the board logic will flip the switch, so the next reset will see flach bank 2 connected to CS0 and thus being the boot device, i. e. the alternative image will be booted.
This is simple, reliable, and doe snot require any special measures in the software, which is completly agnostic to such toggeling.
You may even locate several copies of the environment in both flash banks, so that you have a fully redundant system.
Whether the switch can also be controlled by software or not etc. are details that allow for fine tuning, but I think you get the idea.
But you need a certain level of hardware support - all attempts of nested first and second and third stage loaders and toggeling in software is error prone, because you can be pretty sure that the first problem that will bite you once the systems have been shipped to customers all over the world is not in one of the redundant images, but in the "golden" master copy...
Best regards,
Wolfgang Denk