Dear "J. William Campbell",
In message 4AC660E3.4010404@comcast.net you wrote:
At this point it might be appropriate to ask if including such a reset in udelay() is a good idea. The way it is, no "infinite loop" in u-boot that contains a udelay() will ever allow the watchdog to time out. That
Indeed. We do not have any watchdog preotection for U-Boot itself. U-Boot just makes sure to allow booting an OS with the watchdog activated.
Just because the program invokes udelay, there is no assurance that measurable progress is being made. The udelay may be part of a process that will never complete. Therefore, having a watchdog reset in udelay seems like a less than optimal idea in general. Maybe now would be a good time to look at removing it?
There are other places which have similar issues. For example, you will probably find that most serial drivers (at least those being used on systems with active watchdogs) will have WATCHDOG_RESET() calls in their getc() implementations - which is needed to trigger the WD while the board is in interactive mode, waiting for input.
WD support in U-Boot is just good enough to bridge the time until the OS starts to do the right thing. We do not trry to WD-protect U-Boot itself yet. Implementing such protection would definitely be a good thing to have, but non-trivial effort, too. It would require much more changes than removing the trigger from the udelay() code.
Please feel free to submit patches...
Best regards,
Wolfgang Denk