[PATCH v2 0/8] add basic driver support for broadcom NS3 soc
This is the second patch set series prepared on top of the first patch set ("add initial support for broadcom NS3 soc").
This patch set will add following, -defconfig options for basic device like pinctrl, gpio, mmc, qspi, wdt, i2c and pcie. -start wdt service -Enable GPT commands -Enable EXT4 and FAT fs support
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
-Address review comments from Tom and Simon, Remove all dt patches as uboot should use the same dt file from Linux.
Rayagonda Kokatanur (8): configs: ns3: enable pinctrl driver dt-bindings: pinctrl: add ns3 pads definition configs: ns3: enable BCM IPROC mmc driver configs: ns3: enable mmc commands configs: ns3: enable gpt commands configs: ns3: enable EXT4 and FAT fs support configs: ns3: enable sp805 watchdog driver board: ns3: start sp805 watchdog service
board/broadcom/bcmns3/ns3.c | 50 +++++++++++++++++++ configs/bcm_ns3_defconfig | 19 +++++++ .../dt-bindings/pinctrl/brcm,pinctrl-ns3.h | 41 +++++++++++++++ 3 files changed, 110 insertions(+) create mode 100644 include/dt-bindings/pinctrl/brcm,pinctrl-ns3.h
Enable pinctrl driver for ns3.
Signed-off-by: Rayagonda Kokatanur rayagonda.kokatanur@broadcom.com Reviewed-by: Simon Glass sjg@chromium.org --- configs/bcm_ns3_defconfig | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/configs/bcm_ns3_defconfig b/configs/bcm_ns3_defconfig index 9adb44cb51..328b0e2b4e 100644 --- a/configs/bcm_ns3_defconfig +++ b/configs/bcm_ns3_defconfig @@ -14,12 +14,15 @@ CONFIG_SUPPORT_RAW_INITRD=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="u-boot> " CONFIG_SYS_XTRACE="n" +# CONFIG_CMD_PINMUX is not set # CONFIG_CMD_SOURCE is not set CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="ns3-board" CONFIG_DM=y CONFIG_CLK=y CONFIG_CLK_CCF=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_SINGLE=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y CONFIG_SPL_OF_LIBFDT=y
Add NS3 pads definitions.
Signed-off-by: Rayagonda Kokatanur rayagonda.kokatanur@broadcom.com Reviewed-by: Simon Glass sjg@chromium.org --- .../dt-bindings/pinctrl/brcm,pinctrl-ns3.h | 41 +++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 include/dt-bindings/pinctrl/brcm,pinctrl-ns3.h
diff --git a/include/dt-bindings/pinctrl/brcm,pinctrl-ns3.h b/include/dt-bindings/pinctrl/brcm,pinctrl-ns3.h new file mode 100644 index 0000000000..81ebd58ca5 --- /dev/null +++ b/include/dt-bindings/pinctrl/brcm,pinctrl-ns3.h @@ -0,0 +1,41 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright 2020 Broadcom. + */ + +#ifndef __DT_BINDINGS_PINCTRL_BRCM_STINGRAY_H__ +#define __DT_BINDINGS_PINCTRL_BRCM_STINGRAY_H__ + +/* Alternate functions available in MUX controller */ +#define MODE_NITRO 0 +#define MODE_NAND 1 +#define MODE_PNOR 2 +#define MODE_GPIO 3 + +/* Pad configuration attribute */ +#define PAD_SLEW_RATE_ENA BIT(0) +#define PAD_SLEW_RATE_ENA_MASK BIT(0) + +#define PAD_DRIVE_STRENGTH_2_MA (0 << 1) +#define PAD_DRIVE_STRENGTH_4_MA BIT(1) +#define PAD_DRIVE_STRENGTH_6_MA (2 << 1) +#define PAD_DRIVE_STRENGTH_8_MA (3 << 1) +#define PAD_DRIVE_STRENGTH_10_MA (4 << 1) +#define PAD_DRIVE_STRENGTH_12_MA (5 << 1) +#define PAD_DRIVE_STRENGTH_14_MA (6 << 1) +#define PAD_DRIVE_STRENGTH_16_MA (7 << 1) +#define PAD_DRIVE_STRENGTH_MASK (7 << 1) + +#define PAD_PULL_UP_ENA BIT(4) +#define PAD_PULL_UP_ENA_MASK BIT(4) + +#define PAD_PULL_DOWN_ENA BIT(5) +#define PAD_PULL_DOWN_ENA_MASK BIT(5) + +#define PAD_INPUT_PATH_DIS BIT(6) +#define PAD_INPUT_PATH_DIS_MASK BIT(6) + +#define PAD_HYSTERESIS_ENA BIT(7) +#define PAD_HYSTERESIS_ENA_MASK BIT(7) + +#endif
Enable BCM IPROC mmc driver ns3. Enable DMA for MMC Host to have better reads and writes.
Signed-off-by: Rayagonda Kokatanur rayagonda.kokatanur@broadcom.com Reviewed-by: Simon Glass sjg@chromium.org --- configs/bcm_ns3_defconfig | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/configs/bcm_ns3_defconfig b/configs/bcm_ns3_defconfig index 328b0e2b4e..432237b56d 100644 --- a/configs/bcm_ns3_defconfig +++ b/configs/bcm_ns3_defconfig @@ -21,6 +21,10 @@ CONFIG_DEFAULT_DEVICE_TREE="ns3-board" CONFIG_DM=y CONFIG_CLK=y CONFIG_CLK_CCF=y +CONFIG_DM_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_SDMA=y +CONFIG_MMC_SDHCI_IPROC=y CONFIG_PINCTRL=y CONFIG_PINCTRL_SINGLE=y CONFIG_DM_SERIAL=y
Enable mmc commands for NS3.
Signed-off-by: Rayagonda Kokatanur rayagonda.kokatanur@broadcom.com Reviewed-by: Simon Glass sjg@chromium.org --- configs/bcm_ns3_defconfig | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/configs/bcm_ns3_defconfig b/configs/bcm_ns3_defconfig index 432237b56d..a1ee866e54 100644 --- a/configs/bcm_ns3_defconfig +++ b/configs/bcm_ns3_defconfig @@ -14,6 +14,8 @@ CONFIG_SUPPORT_RAW_INITRD=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="u-boot> " CONFIG_SYS_XTRACE="n" +CONFIG_CMD_MMC=y +CONFIG_CMD_MMC_SWRITE=y # CONFIG_CMD_PINMUX is not set # CONFIG_CMD_SOURCE is not set CONFIG_OF_CONTROL=y
Enable gpt commands for ns3.
Signed-off-by: Rayagonda Kokatanur rayagonda.kokatanur@broadcom.com Reviewed-by: Simon Glass sjg@chromium.org --- configs/bcm_ns3_defconfig | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/configs/bcm_ns3_defconfig b/configs/bcm_ns3_defconfig index a1ee866e54..0f23f30db2 100644 --- a/configs/bcm_ns3_defconfig +++ b/configs/bcm_ns3_defconfig @@ -14,6 +14,8 @@ CONFIG_SUPPORT_RAW_INITRD=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="u-boot> " CONFIG_SYS_XTRACE="n" +CONFIG_CMD_GPT=y +CONFIG_CMD_GPT_RENAME=y CONFIG_CMD_MMC=y CONFIG_CMD_MMC_SWRITE=y # CONFIG_CMD_PINMUX is not set
Enable EXT4 and FAT fs support for ns3.
Signed-off-by: Rayagonda Kokatanur rayagonda.kokatanur@broadcom.com Reviewed-by: Simon Glass sjg@chromium.org --- configs/bcm_ns3_defconfig | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/configs/bcm_ns3_defconfig b/configs/bcm_ns3_defconfig index 0f23f30db2..66fbdb20d6 100644 --- a/configs/bcm_ns3_defconfig +++ b/configs/bcm_ns3_defconfig @@ -20,6 +20,10 @@ CONFIG_CMD_MMC=y CONFIG_CMD_MMC_SWRITE=y # CONFIG_CMD_PINMUX is not set # CONFIG_CMD_SOURCE is not set +CONFIG_CMD_EXT4=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_FAT=y +# CONFIG_DOS_PARTITION is not set CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="ns3-board" CONFIG_DM=y @@ -33,4 +37,5 @@ CONFIG_PINCTRL=y CONFIG_PINCTRL_SINGLE=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y +CONFIG_FAT_WRITE=y CONFIG_SPL_OF_LIBFDT=y
Enable sp805 watchdog driver for ns3.
Signed-off-by: Rayagonda Kokatanur rayagonda.kokatanur@broadcom.com Reviewed-by: Simon Glass sjg@chromium.org --- configs/bcm_ns3_defconfig | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/configs/bcm_ns3_defconfig b/configs/bcm_ns3_defconfig index 66fbdb20d6..3cb69eff9d 100644 --- a/configs/bcm_ns3_defconfig +++ b/configs/bcm_ns3_defconfig @@ -37,5 +37,8 @@ CONFIG_PINCTRL=y CONFIG_PINCTRL_SINGLE=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y +# CONFIG_WATCHDOG is not set +CONFIG_WDT=y +CONFIG_WDT_SP805=y CONFIG_FAT_WRITE=y CONFIG_SPL_OF_LIBFDT=y
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.
Signed-off-by: Rayagonda Kokatanur rayagonda.kokatanur@broadcom.com Signed-off-by: Bharat Kumar Reddy Gooty bharat.gooty@broadcom.com Signed-off-by: Pramod Kumar pramod.kumar@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 */
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@broadcom.com Signed-off-by: Bharat Kumar Reddy Gooty bharat.gooty@broadcom.com Signed-off-by: Pramod Kumar pramod.kumar@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@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@broadcom.com Signed-off-by: Bharat Kumar Reddy Gooty bharat.gooty@broadcom.com Signed-off-by: Pramod Kumar pramod.kumar@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@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@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@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, 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@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?
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@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
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@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.
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@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@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.
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@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@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
participants (2)
-
Rayagonda Kokatanur -
Stefan Roese