Hi Stefan,
On Wed, Jun 17, 2020 at 6:40 PM Stefan Roese sr@denx.de wrote:
Hi Rayagonda,
On 17.06.20 09:44, Rayagonda Kokatanur wrote:
Hi Stefan,
On Thu, Jun 11, 2020 at 4:19 PM Stefan Roese sr@denx.de wrote:
Hi Rayagonda,
On 10.06.20 18:35, Rayagonda Kokatanur wrote:
Hi Stefan,
On Wed, Jun 10, 2020 at 4:33 PM Stefan Roese sr@denx.de wrote:
On 10.06.20 12:52, Rayagonda Kokatanur wrote:
Start sp805 watchdog service.
Parse wdt timeout from env and dts, give precedence to env timeout if defined. Set default timeout to 60s if both env and dts doesn't specifiy timeout.
Stop the WDT in board late init and start the WDT service before giving control to Linux.
I don't really understand, why you need such a board specific watchdog handling. You disable and enable it at some points? Why exactly? Usually the common WDT IF is used and it enables and services the WDT (if configured this way) until the OS is started. Then the OS needs to service the WDT. If the OS fails here (doesn't start correctly etc), then the board will reset via the WDT.
So what is missing in the commin WDT IF for your setup?
Our boot sequence is , first we check for valid Linux images in Linux_part_1, Linux_part_2 and Linux_part_3 of eMMC partition tables. If the Linux image is not available, then we check for a valid Linux image on a USB device. If it is not available in USB devices, then we attempt for PXE boot. We observe the WDT trigger for the PXE boot case.
So the WDT triggers a reset while you are booting via PXE boot? While a image is loaded via PXE boot (pxe command)? If this is the case, I would prefer to fix this issue (WDT reset while running a U-Boot command).
U-boot is used for updating the binaries (like fip.bin {ATF, optee, and uboot}, Linux and file system). For updating, we use tftp protocol, which will take more time and depends up on the network speed.
Hence we stop and start wdt service.
Sure it takes time to update images. But all this should be possible with an actively serviced watchdog while still running in U-Boot. This is why we have all these WATCHDOG_RESET() calls sprinkled all over the system. If some code paths are missing such WDT triggering, then we should find and fix them.
One more issue we are facing is,
So did you work on fixing some of he missing WDT trigger calls?
No, this issue we used to face before this patch.
So you are suggesting to use WATCHDOF_RESET instead of stopping and starting the wdt. WATCHDOG_RESET will take care of resetting wdt in uboot. And it won't lead to system reboot while running any test (ex-i2c read/write test) in uboot or debugging any issue in uboot ?
If we stop at uboot and run some test or analyse some memory to debug some issue, running test or debug may take any time. So if we don't stop wdt service then it will trigger system reset.
Are you talking about using U-Boot via the command line prompt?
Yes.
Using some "md" or other U-Boot commands to debug and test some issues / features? If yes, then this is absolutely common and should be supported by the U-Boot internal watchdog servicing. Its used on many boards for quite some time.
Okay, thank you for the info, will check it.
Or are you talking about some other way to "stop at uboot"? If yes, what exactly do you mean?
No, not any other way.
Thanks Rayagonda
Thanks, Stefan