[PATCH v2 8/8] board: ns3: start sp805 watchdog service

[Rayagonda Kokatanur]

Hi Stefan,

On Wed, Jun 17, 2020 at 6:40 PM Stefan Roese <sr at 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 at 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 at 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