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

[Rayagonda Kokatanur]

Hi Stefan,

On Mon, Jun 22, 2020 at 1:06 PM Stefan Roese <sr at denx.de> wrote:
>
> Hi Rayagonda,
>
> On 21.06.20 12:19, Rayagonda Kokatanur wrote:
> > 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.
>
> Yes.
Thank you.

>
> > 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 ?
>
> Correct. The U-Boot code is "sprinkled" with these calls, easpecially
> ion places where looping might take some time (polling for input etc).
> So the WD timer is triggered / services via this WATCHDOG_RESET call
> to keep U-Boot running even with an active watchdog.

What is the motivation to start watchdog service during uboot and keep
on resetting it.

>
> Thanks,
> Stefan
>
> >>
> >>> 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
>
>
> Viele Grüße,
> Stefan
>
> --
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de