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

[Stefan Roese]

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.

> 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.

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