| Message ID | 20200610105225.31145-9-rayagonda.kokatanur@broadcom.com |
|---|---|
| State | New |
| Headers | show |
| Series | add basic driver support for broadcom NS3 soc | expand |
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? Thanks, Stefan > Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur at broadcom.com> > Signed-off-by: Bharat Kumar Reddy Gooty <bharat.gooty at broadcom.com> > Signed-off-by: Pramod Kumar <pramod.kumar at broadcom.com> > --- > Changes from v1: > -Address review comments from Simon, > -include <dm.h> instead of <dm/device.h> and <dm/uclass.h> > -remove include <fdtdec.h> as its not required > -Use if() instead of #if def > -rearrange code in start_wdt() > -remove #else part of #ifdef CONFIG_DT > > board/broadcom/bcmns3/ns3.c | 50 +++++++++++++++++++++++++++++++++++++ > 1 file changed, 50 insertions(+) > > diff --git a/board/broadcom/bcmns3/ns3.c b/board/broadcom/bcmns3/ns3.c > index 0dd78cde34..1ba6c3fe5d 100644 > --- a/board/broadcom/bcmns3/ns3.c > +++ b/board/broadcom/bcmns3/ns3.c > @@ -5,7 +5,10 @@ > */ > > #include <common.h> > +#include <dm.h> > +#include <env.h> > #include <fdt_support.h> > +#include <wdt.h> > #include <asm/io.h> > #include <asm/gic.h> > #include <asm/gic-v3.h> > @@ -133,6 +136,13 @@ int board_init(void) > > int board_late_init(void) > { > + /* > + * Default WDT service is started with 60 sec time out. > + * Disable it and start before giving control to Linux. > + */ > + if (CONFIG_IS_ENABLED(WDT)) > + wdt_stop(gd->watchdog_dev); > + > return 0; > } > > @@ -184,12 +194,52 @@ void reset_cpu(ulong level) > } > > #ifdef CONFIG_OF_BOARD_SETUP > + > +#ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS > +#define CONFIG_WATCHDOG_TIMEOUT_MSECS (60 * 1000) > +#endif > +#define DEF_TIMEOUT_SEC (CONFIG_WATCHDOG_TIMEOUT_MSECS / 1000) > + > +static int start_wdt(void) > +{ > + u32 timeout = DEF_TIMEOUT_SEC; > + struct udevice *udev; > + int rc = 0; > + u32 wdt_enable; > + > + wdt_enable = env_get_ulong("wdt_enable", 16, 0); > + printf("wdt_enable :%u\n", wdt_enable); > + if (!wdt_enable) > + return rc; > + > + rc = uclass_get_device(UCLASS_WDT, 0, &udev); > + if (rc) { > + printf("Failed to get wdt rc:%d\n", rc); > + return rc; > + } > + > + timeout = env_get_ulong("wdt_timeout_sec", 10, 0); > + if (!timeout) { > + if (CONFIG_IS_ENABLED(OF_CONTROL)) > + timeout = dev_read_u32_default(gd->watchdog_dev, > + "timeout-sec", > + DEF_TIMEOUT_SEC); > + } > + wdt_start(udev, timeout * 1000, 0); > + printf("Started wdt (%ds timeout)\n", timeout); > + > + return rc; > +} > + > int ft_board_setup(void *fdt, bd_t *bd) > { > gic_lpi_tables_init(BCM_NS3_GIC_LPI_BASE, MAX_GIC_REDISTRIBUTORS); > > mem_info_parse_fixup(fdt); > > + if (CONFIG_IS_ENABLED(WDT)) > + start_wdt(); > + > return 0; > } > #endif /* CONFIG_OF_BOARD_SETUP */ > Viele Gr??e, Stefan
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. 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. Best regards, Rayagonda > > > Thanks, > Stefan > > > Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur at broadcom.com> > > Signed-off-by: Bharat Kumar Reddy Gooty <bharat.gooty at broadcom.com> > > Signed-off-by: Pramod Kumar <pramod.kumar at broadcom.com> > > --- > > Changes from v1: > > -Address review comments from Simon, > > -include <dm.h> instead of <dm/device.h> and <dm/uclass.h> > > -remove include <fdtdec.h> as its not required > > -Use if() instead of #if def > > -rearrange code in start_wdt() > > -remove #else part of #ifdef CONFIG_DT > > > > board/broadcom/bcmns3/ns3.c | 50 +++++++++++++++++++++++++++++++++++++ > > 1 file changed, 50 insertions(+) > > > > diff --git a/board/broadcom/bcmns3/ns3.c b/board/broadcom/bcmns3/ns3.c > > index 0dd78cde34..1ba6c3fe5d 100644 > > --- a/board/broadcom/bcmns3/ns3.c > > +++ b/board/broadcom/bcmns3/ns3.c > > @@ -5,7 +5,10 @@ > > */ > > > > #include <common.h> > > +#include <dm.h> > > +#include <env.h> > > #include <fdt_support.h> > > +#include <wdt.h> > > #include <asm/io.h> > > #include <asm/gic.h> > > #include <asm/gic-v3.h> > > @@ -133,6 +136,13 @@ int board_init(void) > > > > int board_late_init(void) > > { > > + /* > > + * Default WDT service is started with 60 sec time out. > > + * Disable it and start before giving control to Linux. > > + */ > > + if (CONFIG_IS_ENABLED(WDT)) > > + wdt_stop(gd->watchdog_dev); > > + > > return 0; > > } > > > > @@ -184,12 +194,52 @@ void reset_cpu(ulong level) > > } > > > > #ifdef CONFIG_OF_BOARD_SETUP > > + > > +#ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS > > +#define CONFIG_WATCHDOG_TIMEOUT_MSECS (60 * 1000) > > +#endif > > +#define DEF_TIMEOUT_SEC (CONFIG_WATCHDOG_TIMEOUT_MSECS / 1000) > > + > > +static int start_wdt(void) > > +{ > > + u32 timeout = DEF_TIMEOUT_SEC; > > + struct udevice *udev; > > + int rc = 0; > > + u32 wdt_enable; > > + > > + wdt_enable = env_get_ulong("wdt_enable", 16, 0); > > + printf("wdt_enable :%u\n", wdt_enable); > > + if (!wdt_enable) > > + return rc; > > + > > + rc = uclass_get_device(UCLASS_WDT, 0, &udev); > > + if (rc) { > > + printf("Failed to get wdt rc:%d\n", rc); > > + return rc; > > + } > > + > > + timeout = env_get_ulong("wdt_timeout_sec", 10, 0); > > + if (!timeout) { > > + if (CONFIG_IS_ENABLED(OF_CONTROL)) > > + timeout = dev_read_u32_default(gd->watchdog_dev, > > + "timeout-sec", > > + DEF_TIMEOUT_SEC); > > + } > > + wdt_start(udev, timeout * 1000, 0); > > + printf("Started wdt (%ds timeout)\n", timeout); > > + > > + return rc; > > +} > > + > > int ft_board_setup(void *fdt, bd_t *bd) > > { > > gic_lpi_tables_init(BCM_NS3_GIC_LPI_BASE, MAX_GIC_REDISTRIBUTORS); > > > > mem_info_parse_fixup(fdt); > > > > + if (CONFIG_IS_ENABLED(WDT)) > > + start_wdt(); > > + > > return 0; > > } > > #endif /* CONFIG_OF_BOARD_SETUP */ > > > > > 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
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. Thanks, Stefan
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, 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. Best regards, Rayagonda > > Thanks, > Stefan
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? > 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? 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. Or are you talking about some other way to "stop at uboot"? If yes, what exactly do you mean? Thanks, Stefan
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
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
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
On 22.06.20 11:33, Rayagonda Kokatanur wrote: <snip> >>>>>> 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. Its similar to why this is done in the OS. There might be execution paths, where the bootloader might crash or hang (loading an image from some device etc). And this WD behavior makes sure, that the system does not hang but reboots in such cases. Thanks, Stefan
On Mon, Jun 22, 2020 at 3:08 PM Stefan Roese <sr at denx.de> wrote: > > On 22.06.20 11:33, Rayagonda Kokatanur wrote: > > <snip> > > >>>>>> 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. > > Its similar to why this is done in the OS. There might be execution > paths, where the bootloader might crash or hang (loading an image > from some device etc). And this WD behavior makes sure, that the > system does not hang but reboots in such cases. Thank you Stefan for the detailed explanation. Best regards, Rayagonda > > Thanks, > Stefan
diff --git a/board/broadcom/bcmns3/ns3.c b/board/broadcom/bcmns3/ns3.c index 0dd78cde34..1ba6c3fe5d 100644 --- a/board/broadcom/bcmns3/ns3.c +++ b/board/broadcom/bcmns3/ns3.c @@ -5,7 +5,10 @@ */ #include <common.h> +#include <dm.h> +#include <env.h> #include <fdt_support.h> +#include <wdt.h> #include <asm/io.h> #include <asm/gic.h> #include <asm/gic-v3.h> @@ -133,6 +136,13 @@ int board_init(void) int board_late_init(void) { + /* + * Default WDT service is started with 60 sec time out. + * Disable it and start before giving control to Linux. + */ + if (CONFIG_IS_ENABLED(WDT)) + wdt_stop(gd->watchdog_dev); + return 0; } @@ -184,12 +194,52 @@ void reset_cpu(ulong level) } #ifdef CONFIG_OF_BOARD_SETUP + +#ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS +#define CONFIG_WATCHDOG_TIMEOUT_MSECS (60 * 1000) +#endif +#define DEF_TIMEOUT_SEC (CONFIG_WATCHDOG_TIMEOUT_MSECS / 1000) + +static int start_wdt(void) +{ + u32 timeout = DEF_TIMEOUT_SEC; + struct udevice *udev; + int rc = 0; + u32 wdt_enable; + + wdt_enable = env_get_ulong("wdt_enable", 16, 0); + printf("wdt_enable :%u\n", wdt_enable); + if (!wdt_enable) + return rc; + + rc = uclass_get_device(UCLASS_WDT, 0, &udev); + if (rc) { + printf("Failed to get wdt rc:%d\n", rc); + return rc; + } + + timeout = env_get_ulong("wdt_timeout_sec", 10, 0); + if (!timeout) { + if (CONFIG_IS_ENABLED(OF_CONTROL)) + timeout = dev_read_u32_default(gd->watchdog_dev, + "timeout-sec", + DEF_TIMEOUT_SEC); + } + wdt_start(udev, timeout * 1000, 0); + printf("Started wdt (%ds timeout)\n", timeout); + + return rc; +} + int ft_board_setup(void *fdt, bd_t *bd) { gic_lpi_tables_init(BCM_NS3_GIC_LPI_BASE, MAX_GIC_REDISTRIBUTORS); mem_info_parse_fixup(fdt); + if (CONFIG_IS_ENABLED(WDT)) + start_wdt(); + return 0; } #endif /* CONFIG_OF_BOARD_SETUP */