* [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support
@ 2020-06-23 11:15 Jan Kiszka
2020-06-23 11:15 ` [PATCH v2 1/3] watchdog: Add support for K3 RTI watchdog Jan Kiszka
` (3 more replies)
0 siblings, 4 replies; 27+ messages in thread
From: Jan Kiszka @ 2020-06-23 11:15 UTC (permalink / raw)
To: u-boot
This brings watchdog support for the TI K3 SoCs, derived from the Linux
kernel, augmented with firmware loading as needed on the AM65x.
Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream
support will be posted soon).
Changes in v2:
- keep watchdog powered when handing over to Linux
- drop unneeded explicit power-on
- account for RTI firmware locking the power domain
Jan
Jan Kiszka (3):
watchdog: Add support for K3 RTI watchdog
watchdog: rti_wdt: Add support for loading firmware
arm: dts: k3: Add RTI watchdogs
arch/arm/dts/k3-am65-mcu.dtsi | 9 ++
arch/arm/dts/k3-j721e-main.dtsi | 18 ++++
drivers/watchdog/Kconfig | 27 ++++++
drivers/watchdog/Makefile | 4 +
drivers/watchdog/rti_wdt.c | 147 ++++++++++++++++++++++++++++++++
drivers/watchdog/rti_wdt_fw.S | 20 +++++
6 files changed, 225 insertions(+)
create mode 100644 drivers/watchdog/rti_wdt.c
create mode 100644 drivers/watchdog/rti_wdt_fw.S
--
2.26.2
^ permalink raw reply [flat|nested] 27+ messages in thread* [PATCH v2 1/3] watchdog: Add support for K3 RTI watchdog 2020-06-23 11:15 [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support Jan Kiszka @ 2020-06-23 11:15 ` Jan Kiszka 2020-06-23 11:47 ` Lokesh Vutla 2020-06-23 11:15 ` [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware Jan Kiszka ` (2 subsequent siblings) 3 siblings, 1 reply; 27+ messages in thread From: Jan Kiszka @ 2020-06-23 11:15 UTC (permalink / raw) To: u-boot From: Jan Kiszka <jan.kiszka@siemens.com> This is based on the Linux kernel driver for the RTI watchdog. To actually reset the system on an AM65x, it requires firmware running on the R5 that accepts the NMI and issues the actual system reset via TISCI. Kind of an iTCO, except that this watchdog hardware has support for no-way-out, and only for that. On the J721E, reset works without extra firmware help when routing the RTI interrupt via the ESM. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- drivers/watchdog/Kconfig | 7 +++ drivers/watchdog/Makefile | 1 + drivers/watchdog/rti_wdt.c | 123 +++++++++++++++++++++++++++++++++++++ 3 files changed, 131 insertions(+) create mode 100644 drivers/watchdog/rti_wdt.c diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index bf06180cdd..ee99bd2af1 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -155,6 +155,13 @@ config WDT_ORION Select this to enable Orion watchdog timer, which can be found on some Marvell Armada chips. +config WDT_K3_RTI + bool "Texas Instruments K3 RTI watchdog" + depends on WDT && ARCH_K3 + help + Say Y here if you want to include support for the K3 watchdog + timer (RTI module) available in the K3 generation of processors. + config WDT_SANDBOX bool "Enable Watchdog Timer support for Sandbox" depends on SANDBOX && WDT diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 519bbd3a40..16bdbf4970 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -27,6 +27,7 @@ obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o obj-$(CONFIG_WDT_MTK) += mtk_wdt.o obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o +obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o obj-$(CONFIG_WDT_SP805) += sp805_wdt.o obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c new file mode 100644 index 0000000000..ebe29c7409 --- /dev/null +++ b/drivers/watchdog/rti_wdt.c @@ -0,0 +1,123 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (c) Siemens AG, 2020 + * + * Authors: + * Jan Kiszka <jan.kiszka@siemens.com> + * + * Derived from linux/drivers/watchdog/rti_wdt.c + */ + +#include <common.h> +#include <clk.h> +#include <dm.h> +#include <power-domain.h> +#include <wdt.h> +#include <asm/io.h> + +/* Timer register set definition */ +#define RTIDWDCTRL 0x90 +#define RTIDWDPRLD 0x94 +#define RTIWDSTATUS 0x98 +#define RTIWDKEY 0x9c +#define RTIDWDCNTR 0xa0 +#define RTIWWDRXCTRL 0xa4 +#define RTIWWDSIZECTRL 0xa8 + +#define RTIWWDRX_NMI 0xa + +#define RTIWWDSIZE_50P 0x50 + +#define WDENABLE_KEY 0xa98559da + +#define WDKEY_SEQ0 0xe51a +#define WDKEY_SEQ1 0xa35c + +#define WDT_PRELOAD_SHIFT 13 + +#define WDT_PRELOAD_MAX 0xfff + +struct rti_wdt_priv { + phys_addr_t regs; + unsigned int clk_khz; +}; + +static int rti_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) +{ + struct rti_wdt_priv *priv = dev_get_priv(dev); + u32 timer_margin; + int ret; + + if (readl(priv->regs + RTIDWDCTRL) == WDENABLE_KEY) + return -EBUSY; + + timer_margin = timeout_ms * priv->clk_khz / 1000; + timer_margin >>= WDT_PRELOAD_SHIFT; + if (timer_margin > WDT_PRELOAD_MAX) + timer_margin = WDT_PRELOAD_MAX; + + writel(timer_margin, priv->regs + RTIDWDPRLD); + writel(RTIWWDRX_NMI, priv->regs + RTIWWDRXCTRL); + writel(RTIWWDSIZE_50P, priv->regs + RTIWWDSIZECTRL); + + readl(priv->regs + RTIWWDSIZECTRL); + + writel(WDENABLE_KEY, priv->regs + RTIDWDCTRL); + + return 0; +} + +static int rti_wdt_reset(struct udevice *dev) +{ + struct rti_wdt_priv *priv = dev_get_priv(dev); + u32 prld; + + /* Make sure we do not reset too early */ + prld = readl(priv->regs + RTIDWDPRLD) << WDT_PRELOAD_SHIFT; + if (readl(priv->regs + RTIDWDCNTR) >= prld / 2) + return -EPERM; + + writel(WDKEY_SEQ0, priv->regs + RTIWDKEY); + writel(WDKEY_SEQ1, priv->regs + RTIWDKEY); + + return 0; +} + +static int rti_wdt_probe(struct udevice *dev) +{ + struct rti_wdt_priv *priv = dev_get_priv(dev); + struct clk clk; + int ret; + + priv->regs = devfdt_get_addr(dev); + if (!priv->regs) + return -EINVAL; + + ret = clk_get_by_index(dev, 0, &clk); + if (ret) + return ret; + + priv->clk_khz = clk_get_rate(&clk); + + return 0; +} + +static const struct wdt_ops rti_wdt_ops = { + .start = rti_wdt_start, + .reset = rti_wdt_reset, +}; + +static const struct udevice_id rti_wdt_ids[] = { + { .compatible = "ti,j7-rti-wdt" }, + { } +}; + +U_BOOT_DRIVER(rti_wdt) = { + .name = "rti_wdt", + .id = UCLASS_WDT, + .of_match = rti_wdt_ids, + .ops = &rti_wdt_ops, + .probe = rti_wdt_probe, + .priv_auto_alloc_size = sizeof(struct rti_wdt_priv), + .flags = DM_FLAG_REMOVE_WITH_PD_ON, +}; -- 2.26.2 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 1/3] watchdog: Add support for K3 RTI watchdog 2020-06-23 11:15 ` [PATCH v2 1/3] watchdog: Add support for K3 RTI watchdog Jan Kiszka @ 2020-06-23 11:47 ` Lokesh Vutla 2020-06-23 12:26 ` Jan Kiszka 0 siblings, 1 reply; 27+ messages in thread From: Lokesh Vutla @ 2020-06-23 11:47 UTC (permalink / raw) To: u-boot On 23/06/20 4:45 pm, Jan Kiszka wrote: > From: Jan Kiszka <jan.kiszka@siemens.com> > > This is based on the Linux kernel driver for the RTI watchdog. > > To actually reset the system on an AM65x, it requires firmware running > on the R5 that accepts the NMI and issues the actual system reset via > TISCI. Kind of an iTCO, except that this watchdog hardware has support > for no-way-out, and only for that. > > On the J721E, reset works without extra firmware help when routing the > RTI interrupt via the ESM. > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > --- > drivers/watchdog/Kconfig | 7 +++ > drivers/watchdog/Makefile | 1 + > drivers/watchdog/rti_wdt.c | 123 +++++++++++++++++++++++++++++++++++++ > 3 files changed, 131 insertions(+) > create mode 100644 drivers/watchdog/rti_wdt.c > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index bf06180cdd..ee99bd2af1 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -155,6 +155,13 @@ config WDT_ORION > Select this to enable Orion watchdog timer, which can be found on some > Marvell Armada chips. > > +config WDT_K3_RTI > + bool "Texas Instruments K3 RTI watchdog" > + depends on WDT && ARCH_K3 > + help > + Say Y here if you want to include support for the K3 watchdog > + timer (RTI module) available in the K3 generation of processors. > + > config WDT_SANDBOX > bool "Enable Watchdog Timer support for Sandbox" > depends on SANDBOX && WDT > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > index 519bbd3a40..16bdbf4970 100644 > --- a/drivers/watchdog/Makefile > +++ b/drivers/watchdog/Makefile > @@ -27,6 +27,7 @@ obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o > obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o > obj-$(CONFIG_WDT_MTK) += mtk_wdt.o > obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o > +obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o > obj-$(CONFIG_WDT_SP805) += sp805_wdt.o > obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o > obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o > diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c > new file mode 100644 > index 0000000000..ebe29c7409 > --- /dev/null > +++ b/drivers/watchdog/rti_wdt.c > @@ -0,0 +1,123 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (c) Siemens AG, 2020 > + * > + * Authors: > + * Jan Kiszka <jan.kiszka@siemens.com> > + * > + * Derived from linux/drivers/watchdog/rti_wdt.c > + */ > + > +#include <common.h> > +#include <clk.h> > +#include <dm.h> > +#include <power-domain.h> > +#include <wdt.h> > +#include <asm/io.h> > + > +/* Timer register set definition */ > +#define RTIDWDCTRL 0x90 > +#define RTIDWDPRLD 0x94 > +#define RTIWDSTATUS 0x98 > +#define RTIWDKEY 0x9c > +#define RTIDWDCNTR 0xa0 > +#define RTIWWDRXCTRL 0xa4 > +#define RTIWWDSIZECTRL 0xa8 > + > +#define RTIWWDRX_NMI 0xa > + > +#define RTIWWDSIZE_50P 0x50 > + > +#define WDENABLE_KEY 0xa98559da > + > +#define WDKEY_SEQ0 0xe51a > +#define WDKEY_SEQ1 0xa35c > + > +#define WDT_PRELOAD_SHIFT 13 > + > +#define WDT_PRELOAD_MAX 0xfff > + > +struct rti_wdt_priv { > + phys_addr_t regs; > + unsigned int clk_khz; > +}; > + > +static int rti_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) > +{ > + struct rti_wdt_priv *priv = dev_get_priv(dev); > + u32 timer_margin; > + int ret; > + > + if (readl(priv->regs + RTIDWDCTRL) == WDENABLE_KEY) > + return -EBUSY; > + > + timer_margin = timeout_ms * priv->clk_khz / 1000; > + timer_margin >>= WDT_PRELOAD_SHIFT; > + if (timer_margin > WDT_PRELOAD_MAX) > + timer_margin = WDT_PRELOAD_MAX; > + > + writel(timer_margin, priv->regs + RTIDWDPRLD); > + writel(RTIWWDRX_NMI, priv->regs + RTIWWDRXCTRL); > + writel(RTIWWDSIZE_50P, priv->regs + RTIWWDSIZECTRL); > + > + readl(priv->regs + RTIWWDSIZECTRL); > + > + writel(WDENABLE_KEY, priv->regs + RTIDWDCTRL); What happens if the watchdog timer expires in U-Boot? Is the watchdog started from U-Boot command line? > + > + return 0; > +} > + > +static int rti_wdt_reset(struct udevice *dev) > +{ > + struct rti_wdt_priv *priv = dev_get_priv(dev); > + u32 prld; > + > + /* Make sure we do not reset too early */ > + prld = readl(priv->regs + RTIDWDPRLD) << WDT_PRELOAD_SHIFT; > + if (readl(priv->regs + RTIDWDCNTR) >= prld / 2) > + return -EPERM; > + > + writel(WDKEY_SEQ0, priv->regs + RTIWDKEY); > + writel(WDKEY_SEQ1, priv->regs + RTIWDKEY); > + > + return 0; > +} > + > +static int rti_wdt_probe(struct udevice *dev) > +{ > + struct rti_wdt_priv *priv = dev_get_priv(dev); > + struct clk clk; > + int ret; > + > + priv->regs = devfdt_get_addr(dev); > + if (!priv->regs) > + return -EINVAL; > + > + ret = clk_get_by_index(dev, 0, &clk); > + if (ret) > + return ret; > + > + priv->clk_khz = clk_get_rate(&clk); > + > + return 0; > +} > + > +static const struct wdt_ops rti_wdt_ops = { > + .start = rti_wdt_start, > + .reset = rti_wdt_reset, > +}; > + > +static const struct udevice_id rti_wdt_ids[] = { > + { .compatible = "ti,j7-rti-wdt" }, Is this compatible matching with Kernel's compatible? Thanks and regards, Lokesh ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 1/3] watchdog: Add support for K3 RTI watchdog 2020-06-23 11:47 ` Lokesh Vutla @ 2020-06-23 12:26 ` Jan Kiszka 0 siblings, 0 replies; 27+ messages in thread From: Jan Kiszka @ 2020-06-23 12:26 UTC (permalink / raw) To: u-boot On 23.06.20 13:47, Lokesh Vutla wrote: > > > On 23/06/20 4:45 pm, Jan Kiszka wrote: >> From: Jan Kiszka <jan.kiszka@siemens.com> >> >> This is based on the Linux kernel driver for the RTI watchdog. >> >> To actually reset the system on an AM65x, it requires firmware running >> on the R5 that accepts the NMI and issues the actual system reset via >> TISCI. Kind of an iTCO, except that this watchdog hardware has support >> for no-way-out, and only for that. >> >> On the J721E, reset works without extra firmware help when routing the >> RTI interrupt via the ESM. >> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >> --- >> drivers/watchdog/Kconfig | 7 +++ >> drivers/watchdog/Makefile | 1 + >> drivers/watchdog/rti_wdt.c | 123 +++++++++++++++++++++++++++++++++++++ >> 3 files changed, 131 insertions(+) >> create mode 100644 drivers/watchdog/rti_wdt.c >> >> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >> index bf06180cdd..ee99bd2af1 100644 >> --- a/drivers/watchdog/Kconfig >> +++ b/drivers/watchdog/Kconfig >> @@ -155,6 +155,13 @@ config WDT_ORION >> Select this to enable Orion watchdog timer, which can be found on some >> Marvell Armada chips. >> >> +config WDT_K3_RTI >> + bool "Texas Instruments K3 RTI watchdog" >> + depends on WDT && ARCH_K3 >> + help >> + Say Y here if you want to include support for the K3 watchdog >> + timer (RTI module) available in the K3 generation of processors. >> + >> config WDT_SANDBOX >> bool "Enable Watchdog Timer support for Sandbox" >> depends on SANDBOX && WDT >> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile >> index 519bbd3a40..16bdbf4970 100644 >> --- a/drivers/watchdog/Makefile >> +++ b/drivers/watchdog/Makefile >> @@ -27,6 +27,7 @@ obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o >> obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o >> obj-$(CONFIG_WDT_MTK) += mtk_wdt.o >> obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o >> +obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o >> obj-$(CONFIG_WDT_SP805) += sp805_wdt.o >> obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o >> obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o >> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c >> new file mode 100644 >> index 0000000000..ebe29c7409 >> --- /dev/null >> +++ b/drivers/watchdog/rti_wdt.c >> @@ -0,0 +1,123 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * Copyright (c) Siemens AG, 2020 >> + * >> + * Authors: >> + * Jan Kiszka <jan.kiszka@siemens.com> >> + * >> + * Derived from linux/drivers/watchdog/rti_wdt.c >> + */ >> + >> +#include <common.h> >> +#include <clk.h> >> +#include <dm.h> >> +#include <power-domain.h> >> +#include <wdt.h> >> +#include <asm/io.h> >> + >> +/* Timer register set definition */ >> +#define RTIDWDCTRL 0x90 >> +#define RTIDWDPRLD 0x94 >> +#define RTIWDSTATUS 0x98 >> +#define RTIWDKEY 0x9c >> +#define RTIDWDCNTR 0xa0 >> +#define RTIWWDRXCTRL 0xa4 >> +#define RTIWWDSIZECTRL 0xa8 >> + >> +#define RTIWWDRX_NMI 0xa >> + >> +#define RTIWWDSIZE_50P 0x50 >> + >> +#define WDENABLE_KEY 0xa98559da >> + >> +#define WDKEY_SEQ0 0xe51a >> +#define WDKEY_SEQ1 0xa35c >> + >> +#define WDT_PRELOAD_SHIFT 13 >> + >> +#define WDT_PRELOAD_MAX 0xfff >> + >> +struct rti_wdt_priv { >> + phys_addr_t regs; >> + unsigned int clk_khz; >> +}; >> + >> +static int rti_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) >> +{ >> + struct rti_wdt_priv *priv = dev_get_priv(dev); >> + u32 timer_margin; >> + int ret; >> + >> + if (readl(priv->regs + RTIDWDCTRL) == WDENABLE_KEY) >> + return -EBUSY; >> + >> + timer_margin = timeout_ms * priv->clk_khz / 1000; >> + timer_margin >>= WDT_PRELOAD_SHIFT; >> + if (timer_margin > WDT_PRELOAD_MAX) >> + timer_margin = WDT_PRELOAD_MAX; >> + >> + writel(timer_margin, priv->regs + RTIDWDPRLD); >> + writel(RTIWWDRX_NMI, priv->regs + RTIWWDRXCTRL); >> + writel(RTIWWDSIZE_50P, priv->regs + RTIWWDSIZECTRL); >> + >> + readl(priv->regs + RTIWWDSIZECTRL); >> + >> + writel(WDENABLE_KEY, priv->regs + RTIDWDCTRL); > > What happens if the watchdog timer expires in U-Boot? > Then we reset. You can feed the watchdog also from U-Boot, just enable CONFIG_WATCHDOG. > Is the watchdog started from U-Boot command line? > U-Boot automatically starts the first watchdog it finds. I didn't find a switch to disable that. If you have multiple watchdogs, you can start others also via "wdt". >> + >> + return 0; >> +} >> + >> +static int rti_wdt_reset(struct udevice *dev) >> +{ >> + struct rti_wdt_priv *priv = dev_get_priv(dev); >> + u32 prld; >> + >> + /* Make sure we do not reset too early */ >> + prld = readl(priv->regs + RTIDWDPRLD) << WDT_PRELOAD_SHIFT; >> + if (readl(priv->regs + RTIDWDCNTR) >= prld / 2) >> + return -EPERM; >> + >> + writel(WDKEY_SEQ0, priv->regs + RTIWDKEY); >> + writel(WDKEY_SEQ1, priv->regs + RTIWDKEY); >> + >> + return 0; >> +} >> + >> +static int rti_wdt_probe(struct udevice *dev) >> +{ >> + struct rti_wdt_priv *priv = dev_get_priv(dev); >> + struct clk clk; >> + int ret; >> + >> + priv->regs = devfdt_get_addr(dev); >> + if (!priv->regs) >> + return -EINVAL; >> + >> + ret = clk_get_by_index(dev, 0, &clk); >> + if (ret) >> + return ret; >> + >> + priv->clk_khz = clk_get_rate(&clk); >> + >> + return 0; >> +} >> + >> +static const struct wdt_ops rti_wdt_ops = { >> + .start = rti_wdt_start, >> + .reset = rti_wdt_reset, >> +}; >> + >> +static const struct udevice_id rti_wdt_ids[] = { >> + { .compatible = "ti,j7-rti-wdt" }, > > Is this compatible matching with Kernel's compatible? > Yes. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware 2020-06-23 11:15 [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support Jan Kiszka 2020-06-23 11:15 ` [PATCH v2 1/3] watchdog: Add support for K3 RTI watchdog Jan Kiszka @ 2020-06-23 11:15 ` Jan Kiszka 2020-06-23 11:50 ` Lokesh Vutla 2020-06-23 11:15 ` [PATCH v2 3/3] arm: dts: k3: Add RTI watchdogs Jan Kiszka 2020-08-11 10:33 ` [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support Lokesh Vutla 3 siblings, 1 reply; 27+ messages in thread From: Jan Kiszka @ 2020-06-23 11:15 UTC (permalink / raw) To: u-boot From: Jan Kiszka <jan.kiszka@siemens.com> To avoid the need of extra boot scripting on AM65x for loading a watchdog firmware, add the required rproc init and loading logic for the first R5F core to the watchdog start handler. The firmware itself is embedded into U-Boot binary. One possible firmware source is https://github.com/siemens/k3-rti-wdt. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- drivers/watchdog/Kconfig | 20 ++++++++++++++++++++ drivers/watchdog/Makefile | 3 +++ drivers/watchdog/rti_wdt.c | 24 ++++++++++++++++++++++++ drivers/watchdog/rti_wdt_fw.S | 20 ++++++++++++++++++++ 4 files changed, 67 insertions(+) create mode 100644 drivers/watchdog/rti_wdt_fw.S diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index ee99bd2af1..fd6ab9a85b 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -162,6 +162,26 @@ config WDT_K3_RTI Say Y here if you want to include support for the K3 watchdog timer (RTI module) available in the K3 generation of processors. +if WDT_K3_RTI + +config WDT_K3_RTI_LOAD_FW + bool "Load watchdog firmware" + depends on REMOTEPROC + help + Automatically load the specified firmware image into the MCU R5F + core 0. On the AM65x, this firmware is supposed to handle the expiry + of the watchdog timer, typically by resetting the system. + +config WDT_K3_RTI_FW_FILE + string "Watchdog firmware image file" + default "k3-rti-wdt.fw" + depends on WDT_K3_RTI_LOAD_FW + help + Firmware image to be embedded into U-Boot and loaded on watchdog + start. + +endif + config WDT_SANDBOX bool "Enable Watchdog Timer support for Sandbox" depends on SANDBOX && WDT diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 16bdbf4970..bf58684875 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o obj-$(CONFIG_WDT_MTK) += mtk_wdt.o obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o obj-$(CONFIG_WDT_SP805) += sp805_wdt.o obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o + +$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c index ebe29c7409..38e82a6b6b 100644 --- a/drivers/watchdog/rti_wdt.c +++ b/drivers/watchdog/rti_wdt.c @@ -14,6 +14,7 @@ #include <power-domain.h> #include <wdt.h> #include <asm/io.h> +#include <remoteproc.h> /* Timer register set definition */ #define RTIDWDCTRL 0x90 @@ -37,11 +38,16 @@ #define WDT_PRELOAD_MAX 0xfff +#define RTI_PROC_ID 0 + struct rti_wdt_priv { phys_addr_t regs; unsigned int clk_khz; }; +extern const u32 rti_wdt_fw[]; +extern const int rti_wdt_fw_size; + static int rti_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) { struct rti_wdt_priv *priv = dev_get_priv(dev); @@ -51,6 +57,24 @@ static int rti_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags) if (readl(priv->regs + RTIDWDCTRL) == WDENABLE_KEY) return -EBUSY; +#ifdef CONFIG_WDT_K3_RTI_LOAD_FW + ret = rproc_dev_init(RTI_PROC_ID); + if (ret) { + fw_error: + dev_err(dev, "Failed to load watchdog firmware into remote processor %d\n", + RTI_PROC_ID); + return ret; + } + + ret = rproc_load(RTI_PROC_ID, (ulong)rti_wdt_fw, rti_wdt_fw_size); + if (ret) + goto fw_error; + + ret = rproc_start(RTI_PROC_ID); + if (ret) + goto fw_error; +#endif + timer_margin = timeout_ms * priv->clk_khz / 1000; timer_margin >>= WDT_PRELOAD_SHIFT; if (timer_margin > WDT_PRELOAD_MAX) diff --git a/drivers/watchdog/rti_wdt_fw.S b/drivers/watchdog/rti_wdt_fw.S new file mode 100644 index 0000000000..78d99ff9f2 --- /dev/null +++ b/drivers/watchdog/rti_wdt_fw.S @@ -0,0 +1,20 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (c) Siemens AG, 2020 + * + * Authors: + * Jan Kiszka <jan.kiszka@siemens.com> + */ + +.section .rodata + +.global rti_wdt_fw +.global rti_wdt_fw_size + +rti_wdt_fw: +.align 4 +.incbin CONFIG_WDT_K3_RTI_FW_FILE +rti_wdt_fw_end: + +rti_wdt_fw_size: +.int rti_wdt_fw_end - rti_wdt_fw -- 2.26.2 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware 2020-06-23 11:15 ` [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware Jan Kiszka @ 2020-06-23 11:50 ` Lokesh Vutla 2020-06-23 12:37 ` Jan Kiszka 0 siblings, 1 reply; 27+ messages in thread From: Lokesh Vutla @ 2020-06-23 11:50 UTC (permalink / raw) To: u-boot On 23/06/20 4:45 pm, Jan Kiszka wrote: > From: Jan Kiszka <jan.kiszka@siemens.com> > > To avoid the need of extra boot scripting on AM65x for loading a > watchdog firmware, add the required rproc init and loading logic for the > first R5F core to the watchdog start handler. The firmware itself is > embedded into U-Boot binary. > > One possible firmware source is https://github.com/siemens/k3-rti-wdt. > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > --- > drivers/watchdog/Kconfig | 20 ++++++++++++++++++++ > drivers/watchdog/Makefile | 3 +++ > drivers/watchdog/rti_wdt.c | 24 ++++++++++++++++++++++++ > drivers/watchdog/rti_wdt_fw.S | 20 ++++++++++++++++++++ > 4 files changed, 67 insertions(+) > create mode 100644 drivers/watchdog/rti_wdt_fw.S > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index ee99bd2af1..fd6ab9a85b 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -162,6 +162,26 @@ config WDT_K3_RTI > Say Y here if you want to include support for the K3 watchdog > timer (RTI module) available in the K3 generation of processors. > > +if WDT_K3_RTI > + > +config WDT_K3_RTI_LOAD_FW > + bool "Load watchdog firmware" > + depends on REMOTEPROC > + help > + Automatically load the specified firmware image into the MCU R5F > + core 0. On the AM65x, this firmware is supposed to handle the expiry > + of the watchdog timer, typically by resetting the system. > + > +config WDT_K3_RTI_FW_FILE > + string "Watchdog firmware image file" > + default "k3-rti-wdt.fw" > + depends on WDT_K3_RTI_LOAD_FW > + help > + Firmware image to be embedded into U-Boot and loaded on watchdog > + start. > + > +endif > + > config WDT_SANDBOX > bool "Enable Watchdog Timer support for Sandbox" > depends on SANDBOX && WDT > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > index 16bdbf4970..bf58684875 100644 > --- a/drivers/watchdog/Makefile > +++ b/drivers/watchdog/Makefile > @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o > obj-$(CONFIG_WDT_MTK) += mtk_wdt.o > obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o > obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o > +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o > obj-$(CONFIG_WDT_SP805) += sp805_wdt.o > obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o > obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o > obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o > + > +$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE > diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c > index ebe29c7409..38e82a6b6b 100644 > --- a/drivers/watchdog/rti_wdt.c > +++ b/drivers/watchdog/rti_wdt.c > @@ -14,6 +14,7 @@ > #include <power-domain.h> > #include <wdt.h> > #include <asm/io.h> > +#include <remoteproc.h> > > /* Timer register set definition */ > #define RTIDWDCTRL 0x90 > @@ -37,11 +38,16 @@ > > #define WDT_PRELOAD_MAX 0xfff > > +#define RTI_PROC_ID 0 Can we get the rproc id from DT? > + > struct rti_wdt_priv { > phys_addr_t regs; > unsigned int clk_khz; > }; > > +extern const u32 rti_wdt_fw[]; > +extern const int rti_wdt_fw_size; FIT is the preferred way of packing images in U-Boot. Can you try using it? Thanks and regards, Lokesh ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware 2020-06-23 11:50 ` Lokesh Vutla @ 2020-06-23 12:37 ` Jan Kiszka 2020-06-23 14:41 ` Jan Kiszka 0 siblings, 1 reply; 27+ messages in thread From: Jan Kiszka @ 2020-06-23 12:37 UTC (permalink / raw) To: u-boot On 23.06.20 13:50, Lokesh Vutla wrote: > > > On 23/06/20 4:45 pm, Jan Kiszka wrote: >> From: Jan Kiszka <jan.kiszka@siemens.com> >> >> To avoid the need of extra boot scripting on AM65x for loading a >> watchdog firmware, add the required rproc init and loading logic for the >> first R5F core to the watchdog start handler. The firmware itself is >> embedded into U-Boot binary. >> >> One possible firmware source is https://github.com/siemens/k3-rti-wdt. >> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >> --- >> drivers/watchdog/Kconfig | 20 ++++++++++++++++++++ >> drivers/watchdog/Makefile | 3 +++ >> drivers/watchdog/rti_wdt.c | 24 ++++++++++++++++++++++++ >> drivers/watchdog/rti_wdt_fw.S | 20 ++++++++++++++++++++ >> 4 files changed, 67 insertions(+) >> create mode 100644 drivers/watchdog/rti_wdt_fw.S >> >> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >> index ee99bd2af1..fd6ab9a85b 100644 >> --- a/drivers/watchdog/Kconfig >> +++ b/drivers/watchdog/Kconfig >> @@ -162,6 +162,26 @@ config WDT_K3_RTI >> Say Y here if you want to include support for the K3 watchdog >> timer (RTI module) available in the K3 generation of processors. >> >> +if WDT_K3_RTI >> + >> +config WDT_K3_RTI_LOAD_FW >> + bool "Load watchdog firmware" >> + depends on REMOTEPROC >> + help >> + Automatically load the specified firmware image into the MCU R5F >> + core 0. On the AM65x, this firmware is supposed to handle the expiry >> + of the watchdog timer, typically by resetting the system. >> + >> +config WDT_K3_RTI_FW_FILE >> + string "Watchdog firmware image file" >> + default "k3-rti-wdt.fw" >> + depends on WDT_K3_RTI_LOAD_FW >> + help >> + Firmware image to be embedded into U-Boot and loaded on watchdog >> + start. >> + >> +endif >> + >> config WDT_SANDBOX >> bool "Enable Watchdog Timer support for Sandbox" >> depends on SANDBOX && WDT >> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile >> index 16bdbf4970..bf58684875 100644 >> --- a/drivers/watchdog/Makefile >> +++ b/drivers/watchdog/Makefile >> @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o >> obj-$(CONFIG_WDT_MTK) += mtk_wdt.o >> obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o >> obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o >> +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o >> obj-$(CONFIG_WDT_SP805) += sp805_wdt.o >> obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o >> obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o >> obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o >> + >> +$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE >> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c >> index ebe29c7409..38e82a6b6b 100644 >> --- a/drivers/watchdog/rti_wdt.c >> +++ b/drivers/watchdog/rti_wdt.c >> @@ -14,6 +14,7 @@ >> #include <power-domain.h> >> #include <wdt.h> >> #include <asm/io.h> >> +#include <remoteproc.h> >> >> /* Timer register set definition */ >> #define RTIDWDCTRL 0x90 >> @@ -37,11 +38,16 @@ >> >> #define WDT_PRELOAD_MAX 0xfff >> >> +#define RTI_PROC_ID 0 > > Can we get the rproc id from DT? You mean, resolve "mcu_r5fss0_core0" to the ID? Doable. > >> + >> struct rti_wdt_priv { >> phys_addr_t regs; >> unsigned int clk_khz; >> }; >> >> +extern const u32 rti_wdt_fw[]; >> +extern const int rti_wdt_fw_size; > > FIT is the preferred way of packing images in U-Boot. Can you try using it? How does that work? Some example for me? What benefit would that bring? There are other users of this pattern, e.g. board/xilinx/zynqmp/pm_cfg_obj.S. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware 2020-06-23 12:37 ` Jan Kiszka @ 2020-06-23 14:41 ` Jan Kiszka 2020-06-29 2:26 ` Lokesh Vutla 0 siblings, 1 reply; 27+ messages in thread From: Jan Kiszka @ 2020-06-23 14:41 UTC (permalink / raw) To: u-boot On 23.06.20 14:37, Jan Kiszka wrote: > On 23.06.20 13:50, Lokesh Vutla wrote: >> >> >> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>> From: Jan Kiszka <jan.kiszka@siemens.com> >>> >>> To avoid the need of extra boot scripting on AM65x for loading a >>> watchdog firmware, add the required rproc init and loading logic for the >>> first R5F core to the watchdog start handler. The firmware itself is >>> embedded into U-Boot binary. >>> >>> One possible firmware source is https://github.com/siemens/k3-rti-wdt. >>> >>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>> --- >>> ? drivers/watchdog/Kconfig????? | 20 ++++++++++++++++++++ >>> ? drivers/watchdog/Makefile???? |? 3 +++ >>> ? drivers/watchdog/rti_wdt.c??? | 24 ++++++++++++++++++++++++ >>> ? drivers/watchdog/rti_wdt_fw.S | 20 ++++++++++++++++++++ >>> ? 4 files changed, 67 insertions(+) >>> ? create mode 100644 drivers/watchdog/rti_wdt_fw.S >>> >>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >>> index ee99bd2af1..fd6ab9a85b 100644 >>> --- a/drivers/watchdog/Kconfig >>> +++ b/drivers/watchdog/Kconfig >>> @@ -162,6 +162,26 @@ config WDT_K3_RTI >>> ??????? Say Y here if you want to include support for the K3 watchdog >>> ??????? timer (RTI module) available in the K3 generation of processors. >>> +if WDT_K3_RTI >>> + >>> +config WDT_K3_RTI_LOAD_FW >>> +??? bool "Load watchdog firmware" >>> +??? depends on REMOTEPROC >>> +??? help >>> +????? Automatically load the specified firmware image into the MCU R5F >>> +????? core 0. On the AM65x, this firmware is supposed to handle the >>> expiry >>> +????? of the watchdog timer, typically by resetting the system. >>> + >>> +config WDT_K3_RTI_FW_FILE >>> +??? string "Watchdog firmware image file" >>> +??? default "k3-rti-wdt.fw" >>> +??? depends on WDT_K3_RTI_LOAD_FW >>> +??? help >>> +????? Firmware image to be embedded into U-Boot and loaded on watchdog >>> +????? start. >>> + >>> +endif >>> + >>> ? config WDT_SANDBOX >>> ????? bool "Enable Watchdog Timer support for Sandbox" >>> ????? depends on SANDBOX && WDT >>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile >>> index 16bdbf4970..bf58684875 100644 >>> --- a/drivers/watchdog/Makefile >>> +++ b/drivers/watchdog/Makefile >>> @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o >>> ? obj-$(CONFIG_WDT_MTK) += mtk_wdt.o >>> ? obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o >>> ? obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o >>> +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o >>> ? obj-$(CONFIG_WDT_SP805) += sp805_wdt.o >>> ? obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o >>> ? obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o >>> ? obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o >>> + >>> +$(obj)/rti_wdt_fw.o: $(shell readlink -f >>> $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE >>> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c >>> index ebe29c7409..38e82a6b6b 100644 >>> --- a/drivers/watchdog/rti_wdt.c >>> +++ b/drivers/watchdog/rti_wdt.c >>> @@ -14,6 +14,7 @@ >>> ? #include <power-domain.h> >>> ? #include <wdt.h> >>> ? #include <asm/io.h> >>> +#include <remoteproc.h> >>> ? /* Timer register set definition */ >>> ? #define RTIDWDCTRL??????? 0x90 >>> @@ -37,11 +38,16 @@ >>> ? #define WDT_PRELOAD_MAX??????? 0xfff >>> +#define RTI_PROC_ID??????? 0 >> >> Can we get the rproc id from DT? > > You mean, resolve "mcu_r5fss0_core0" to the ID? Doable. > I'm now probing for the first instance of "ti,am654-r5f" compatible. That excludes usage for the J721E for now, but that one is fine without firmware - provided there is way to prevent power-down for RTI watchdog otherwise... >> >>> + >>> ? struct rti_wdt_priv { >>> ????? phys_addr_t regs; >>> ????? unsigned int clk_khz; >>> ? }; >>> +extern const u32 rti_wdt_fw[]; >>> +extern const int rti_wdt_fw_size; >> >> FIT is the preferred way of packing images in U-Boot. Can you try >> using it? > > How does that work? Some example for me? > If you happen to refer to fs-loader: That does not target OSPI, our primary use case. > What benefit would that bring? There are other users of this pattern, > e.g. board/xilinx/zynqmp/pm_cfg_obj.S. > The only benefit of an alternative loading mechanism seems to be handling of larger images from different sources. But that's what I would tackle via boot scripting and, thus, without this feature. If you only have a few hundred bytes to embed, like for k3-rti-wdt, you quickly have a lot of overhead with other approaches. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware 2020-06-23 14:41 ` Jan Kiszka @ 2020-06-29 2:26 ` Lokesh Vutla 2020-06-29 4:50 ` Jan Kiszka 2020-06-29 12:37 ` Tom Rini 0 siblings, 2 replies; 27+ messages in thread From: Lokesh Vutla @ 2020-06-29 2:26 UTC (permalink / raw) To: u-boot +Tom On 23/06/20 8:11 pm, Jan Kiszka wrote: > On 23.06.20 14:37, Jan Kiszka wrote: >> On 23.06.20 13:50, Lokesh Vutla wrote: >>> >>> >>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>> >>>> To avoid the need of extra boot scripting on AM65x for loading a >>>> watchdog firmware, add the required rproc init and loading logic for the >>>> first R5F core to the watchdog start handler. The firmware itself is >>>> embedded into U-Boot binary. >>>> >>>> One possible firmware source is https://github.com/siemens/k3-rti-wdt. >>>> >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>> --- >>>> ? drivers/watchdog/Kconfig????? | 20 ++++++++++++++++++++ >>>> ? drivers/watchdog/Makefile???? |? 3 +++ >>>> ? drivers/watchdog/rti_wdt.c??? | 24 ++++++++++++++++++++++++ >>>> ? drivers/watchdog/rti_wdt_fw.S | 20 ++++++++++++++++++++ >>>> ? 4 files changed, 67 insertions(+) >>>> ? create mode 100644 drivers/watchdog/rti_wdt_fw.S >>>> >>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >>>> index ee99bd2af1..fd6ab9a85b 100644 >>>> --- a/drivers/watchdog/Kconfig >>>> +++ b/drivers/watchdog/Kconfig >>>> @@ -162,6 +162,26 @@ config WDT_K3_RTI >>>> ??????? Say Y here if you want to include support for the K3 watchdog >>>> ??????? timer (RTI module) available in the K3 generation of processors. >>>> +if WDT_K3_RTI >>>> + >>>> +config WDT_K3_RTI_LOAD_FW >>>> +??? bool "Load watchdog firmware" >>>> +??? depends on REMOTEPROC >>>> +??? help >>>> +????? Automatically load the specified firmware image into the MCU R5F >>>> +????? core 0. On the AM65x, this firmware is supposed to handle the expiry >>>> +????? of the watchdog timer, typically by resetting the system. >>>> + >>>> +config WDT_K3_RTI_FW_FILE >>>> +??? string "Watchdog firmware image file" >>>> +??? default "k3-rti-wdt.fw" >>>> +??? depends on WDT_K3_RTI_LOAD_FW >>>> +??? help >>>> +????? Firmware image to be embedded into U-Boot and loaded on watchdog >>>> +????? start. >>>> + >>>> +endif >>>> + >>>> ? config WDT_SANDBOX >>>> ????? bool "Enable Watchdog Timer support for Sandbox" >>>> ????? depends on SANDBOX && WDT >>>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile >>>> index 16bdbf4970..bf58684875 100644 >>>> --- a/drivers/watchdog/Makefile >>>> +++ b/drivers/watchdog/Makefile >>>> @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o >>>> ? obj-$(CONFIG_WDT_MTK) += mtk_wdt.o >>>> ? obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o >>>> ? obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o >>>> +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o >>>> ? obj-$(CONFIG_WDT_SP805) += sp805_wdt.o >>>> ? obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o >>>> ? obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o >>>> ? obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o >>>> + >>>> +$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE >>>> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c >>>> index ebe29c7409..38e82a6b6b 100644 >>>> --- a/drivers/watchdog/rti_wdt.c >>>> +++ b/drivers/watchdog/rti_wdt.c >>>> @@ -14,6 +14,7 @@ >>>> ? #include <power-domain.h> >>>> ? #include <wdt.h> >>>> ? #include <asm/io.h> >>>> +#include <remoteproc.h> >>>> ? /* Timer register set definition */ >>>> ? #define RTIDWDCTRL??????? 0x90 >>>> @@ -37,11 +38,16 @@ >>>> ? #define WDT_PRELOAD_MAX??????? 0xfff >>>> +#define RTI_PROC_ID??????? 0 >>> >>> Can we get the rproc id from DT? >> >> You mean, resolve "mcu_r5fss0_core0" to the ID? Doable. >> > > I'm now probing for the first instance of "ti,am654-r5f" compatible. That > excludes usage for the J721E for now, but that one is fine without firmware - > provided there is way to prevent power-down for RTI watchdog otherwise... I was more of thinking to have a DT property to reference R5-core. But anyways, the property is not present in kernel. I am okay with this for now. > >>> >>>> + >>>> ? struct rti_wdt_priv { >>>> ????? phys_addr_t regs; >>>> ????? unsigned int clk_khz; >>>> ? }; >>>> +extern const u32 rti_wdt_fw[]; >>>> +extern const int rti_wdt_fw_size; >>> >>> FIT is the preferred way of packing images in U-Boot. Can you try using it? >> >> How does that work? Some example for me? >> > > If you happen to refer to fs-loader: That does not target OSPI, our primary use > case. No. I was thinking to pack the image in FIT along with ATF and OPTEE like in k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for installing the firmware. > >> What benefit would that bring? There are other users of this pattern, e.g. >> board/xilinx/zynqmp/pm_cfg_obj.S. I didn't know U-Boot is accepting this. Tom, is this the preferred way for including firmware images? >> > > The only benefit of an alternative loading mechanism seems to be handling of > larger images from different sources. But that's what I would tackle via boot > scripting and, thus, without this feature. If you only have a few hundred bytes > to embed, like for k3-rti-wdt, you quickly have a lot of overhead with other > approaches. hmm.. Does the build break if firmware is not present? Thanks and regards, Lokesh > > Jan > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware 2020-06-29 2:26 ` Lokesh Vutla @ 2020-06-29 4:50 ` Jan Kiszka 2020-06-29 4:54 ` Lokesh Vutla 2020-06-29 12:37 ` Tom Rini 1 sibling, 1 reply; 27+ messages in thread From: Jan Kiszka @ 2020-06-29 4:50 UTC (permalink / raw) To: u-boot On 29.06.20 04:26, Lokesh Vutla wrote: > +Tom > > On 23/06/20 8:11 pm, Jan Kiszka wrote: >> On 23.06.20 14:37, Jan Kiszka wrote: >>> On 23.06.20 13:50, Lokesh Vutla wrote: >>>> >>>> >>>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>> >>>>> To avoid the need of extra boot scripting on AM65x for loading a >>>>> watchdog firmware, add the required rproc init and loading logic for the >>>>> first R5F core to the watchdog start handler. The firmware itself is >>>>> embedded into U-Boot binary. >>>>> >>>>> One possible firmware source is https://github.com/siemens/k3-rti-wdt. >>>>> >>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>>> --- >>>>> ? drivers/watchdog/Kconfig????? | 20 ++++++++++++++++++++ >>>>> ? drivers/watchdog/Makefile???? |? 3 +++ >>>>> ? drivers/watchdog/rti_wdt.c??? | 24 ++++++++++++++++++++++++ >>>>> ? drivers/watchdog/rti_wdt_fw.S | 20 ++++++++++++++++++++ >>>>> ? 4 files changed, 67 insertions(+) >>>>> ? create mode 100644 drivers/watchdog/rti_wdt_fw.S >>>>> >>>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >>>>> index ee99bd2af1..fd6ab9a85b 100644 >>>>> --- a/drivers/watchdog/Kconfig >>>>> +++ b/drivers/watchdog/Kconfig >>>>> @@ -162,6 +162,26 @@ config WDT_K3_RTI >>>>> ??????? Say Y here if you want to include support for the K3 watchdog >>>>> ??????? timer (RTI module) available in the K3 generation of processors. >>>>> +if WDT_K3_RTI >>>>> + >>>>> +config WDT_K3_RTI_LOAD_FW >>>>> +??? bool "Load watchdog firmware" >>>>> +??? depends on REMOTEPROC >>>>> +??? help >>>>> +????? Automatically load the specified firmware image into the MCU R5F >>>>> +????? core 0. On the AM65x, this firmware is supposed to handle the expiry >>>>> +????? of the watchdog timer, typically by resetting the system. >>>>> + >>>>> +config WDT_K3_RTI_FW_FILE >>>>> +??? string "Watchdog firmware image file" >>>>> +??? default "k3-rti-wdt.fw" >>>>> +??? depends on WDT_K3_RTI_LOAD_FW >>>>> +??? help >>>>> +????? Firmware image to be embedded into U-Boot and loaded on watchdog >>>>> +????? start. >>>>> + >>>>> +endif >>>>> + >>>>> ? config WDT_SANDBOX >>>>> ????? bool "Enable Watchdog Timer support for Sandbox" >>>>> ????? depends on SANDBOX && WDT >>>>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile >>>>> index 16bdbf4970..bf58684875 100644 >>>>> --- a/drivers/watchdog/Makefile >>>>> +++ b/drivers/watchdog/Makefile >>>>> @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o >>>>> ? obj-$(CONFIG_WDT_MTK) += mtk_wdt.o >>>>> ? obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o >>>>> ? obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o >>>>> +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o >>>>> ? obj-$(CONFIG_WDT_SP805) += sp805_wdt.o >>>>> ? obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o >>>>> ? obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o >>>>> ? obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o >>>>> + >>>>> +$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE >>>>> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c >>>>> index ebe29c7409..38e82a6b6b 100644 >>>>> --- a/drivers/watchdog/rti_wdt.c >>>>> +++ b/drivers/watchdog/rti_wdt.c >>>>> @@ -14,6 +14,7 @@ >>>>> ? #include <power-domain.h> >>>>> ? #include <wdt.h> >>>>> ? #include <asm/io.h> >>>>> +#include <remoteproc.h> >>>>> ? /* Timer register set definition */ >>>>> ? #define RTIDWDCTRL??????? 0x90 >>>>> @@ -37,11 +38,16 @@ >>>>> ? #define WDT_PRELOAD_MAX??????? 0xfff >>>>> +#define RTI_PROC_ID??????? 0 >>>> >>>> Can we get the rproc id from DT? >>> >>> You mean, resolve "mcu_r5fss0_core0" to the ID? Doable. >>> >> >> I'm now probing for the first instance of "ti,am654-r5f" compatible. That >> excludes usage for the J721E for now, but that one is fine without firmware - >> provided there is way to prevent power-down for RTI watchdog otherwise... > > I was more of thinking to have a DT property to reference R5-core. But anyways, > the property is not present in kernel. I am okay with this for now. > >> >>>> >>>>> + >>>>> ? struct rti_wdt_priv { >>>>> ????? phys_addr_t regs; >>>>> ????? unsigned int clk_khz; >>>>> ? }; >>>>> +extern const u32 rti_wdt_fw[]; >>>>> +extern const int rti_wdt_fw_size; >>>> >>>> FIT is the preferred way of packing images in U-Boot. Can you try using it? >>> >>> How does that work? Some example for me? >>> >> >> If you happen to refer to fs-loader: That does not target OSPI, our primary use >> case. > > No. I was thinking to pack the image in FIT along with ATF and OPTEE like in > k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for installing the > firmware. In case of our board, that image is not processed by U-Boot (only generated). Also, processing it from the R5 loader would imply putting remoteproc support into that level, duplicating what we have in A53 U-Boot. > >> >>> What benefit would that bring? There are other users of this pattern, e.g. >>> board/xilinx/zynqmp/pm_cfg_obj.S. > > I didn't know U-Boot is accepting this. Tom, is this the preferred way for > including firmware images? > >>> >> >> The only benefit of an alternative loading mechanism seems to be handling of >> larger images from different sources. But that's what I would tackle via boot >> scripting and, thus, without this feature. If you only have a few hundred bytes >> to embed, like for k3-rti-wdt, you quickly have a lot of overhead with other >> approaches. > > hmm.. Does the build break if firmware is not present? Yes, if you configure to include the firmware but specify an invalid path, the build breaks. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware 2020-06-29 4:50 ` Jan Kiszka @ 2020-06-29 4:54 ` Lokesh Vutla 2020-06-29 7:44 ` Jan Kiszka 0 siblings, 1 reply; 27+ messages in thread From: Lokesh Vutla @ 2020-06-29 4:54 UTC (permalink / raw) To: u-boot On 29/06/20 10:20 am, Jan Kiszka wrote: > On 29.06.20 04:26, Lokesh Vutla wrote: >> +Tom >> >> On 23/06/20 8:11 pm, Jan Kiszka wrote: >>> On 23.06.20 14:37, Jan Kiszka wrote: >>>> On 23.06.20 13:50, Lokesh Vutla wrote: >>>>> >>>>> >>>>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>>> >>>>>> To avoid the need of extra boot scripting on AM65x for loading a >>>>>> watchdog firmware, add the required rproc init and loading logic for the >>>>>> first R5F core to the watchdog start handler. The firmware itself is >>>>>> embedded into U-Boot binary. >>>>>> >>>>>> One possible firmware source is https://github.com/siemens/k3-rti-wdt. >>>>>> >>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>>>> --- >>>>>> ?? drivers/watchdog/Kconfig????? | 20 ++++++++++++++++++++ >>>>>> ?? drivers/watchdog/Makefile???? |? 3 +++ >>>>>> ?? drivers/watchdog/rti_wdt.c??? | 24 ++++++++++++++++++++++++ >>>>>> ?? drivers/watchdog/rti_wdt_fw.S | 20 ++++++++++++++++++++ >>>>>> ?? 4 files changed, 67 insertions(+) >>>>>> ?? create mode 100644 drivers/watchdog/rti_wdt_fw.S >>>>>> >>>>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >>>>>> index ee99bd2af1..fd6ab9a85b 100644 >>>>>> --- a/drivers/watchdog/Kconfig >>>>>> +++ b/drivers/watchdog/Kconfig >>>>>> @@ -162,6 +162,26 @@ config WDT_K3_RTI >>>>>> ???????? Say Y here if you want to include support for the K3 watchdog >>>>>> ???????? timer (RTI module) available in the K3 generation of processors. >>>>>> +if WDT_K3_RTI >>>>>> + >>>>>> +config WDT_K3_RTI_LOAD_FW >>>>>> +??? bool "Load watchdog firmware" >>>>>> +??? depends on REMOTEPROC >>>>>> +??? help >>>>>> +????? Automatically load the specified firmware image into the MCU R5F >>>>>> +????? core 0. On the AM65x, this firmware is supposed to handle the expiry >>>>>> +????? of the watchdog timer, typically by resetting the system. >>>>>> + >>>>>> +config WDT_K3_RTI_FW_FILE >>>>>> +??? string "Watchdog firmware image file" >>>>>> +??? default "k3-rti-wdt.fw" >>>>>> +??? depends on WDT_K3_RTI_LOAD_FW >>>>>> +??? help >>>>>> +????? Firmware image to be embedded into U-Boot and loaded on watchdog >>>>>> +????? start. >>>>>> + >>>>>> +endif >>>>>> + >>>>>> ?? config WDT_SANDBOX >>>>>> ?????? bool "Enable Watchdog Timer support for Sandbox" >>>>>> ?????? depends on SANDBOX && WDT >>>>>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile >>>>>> index 16bdbf4970..bf58684875 100644 >>>>>> --- a/drivers/watchdog/Makefile >>>>>> +++ b/drivers/watchdog/Makefile >>>>>> @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o >>>>>> ?? obj-$(CONFIG_WDT_MTK) += mtk_wdt.o >>>>>> ?? obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o >>>>>> ?? obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o >>>>>> +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o >>>>>> ?? obj-$(CONFIG_WDT_SP805) += sp805_wdt.o >>>>>> ?? obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o >>>>>> ?? obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o >>>>>> ?? obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o >>>>>> + >>>>>> +$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE >>>>>> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c >>>>>> index ebe29c7409..38e82a6b6b 100644 >>>>>> --- a/drivers/watchdog/rti_wdt.c >>>>>> +++ b/drivers/watchdog/rti_wdt.c >>>>>> @@ -14,6 +14,7 @@ >>>>>> ?? #include <power-domain.h> >>>>>> ?? #include <wdt.h> >>>>>> ?? #include <asm/io.h> >>>>>> +#include <remoteproc.h> >>>>>> ?? /* Timer register set definition */ >>>>>> ?? #define RTIDWDCTRL??????? 0x90 >>>>>> @@ -37,11 +38,16 @@ >>>>>> ?? #define WDT_PRELOAD_MAX??????? 0xfff >>>>>> +#define RTI_PROC_ID??????? 0 >>>>> >>>>> Can we get the rproc id from DT? >>>> >>>> You mean, resolve "mcu_r5fss0_core0" to the ID? Doable. >>>> >>> >>> I'm now probing for the first instance of "ti,am654-r5f" compatible. That >>> excludes usage for the J721E for now, but that one is fine without firmware - >>> provided there is way to prevent power-down for RTI watchdog otherwise... >> >> I was more of thinking to have a DT property to reference R5-core. But anyways, >> the property is not present in kernel. I am okay with this for now. >> >>> >>>>> >>>>>> + >>>>>> ?? struct rti_wdt_priv { >>>>>> ?????? phys_addr_t regs; >>>>>> ?????? unsigned int clk_khz; >>>>>> ?? }; >>>>>> +extern const u32 rti_wdt_fw[]; >>>>>> +extern const int rti_wdt_fw_size; >>>>> >>>>> FIT is the preferred way of packing images in U-Boot. Can you try using it? >>>> >>>> How does that work? Some example for me? >>>> >>> >>> If you happen to refer to fs-loader: That does not target OSPI, our primary use >>> case. >> >> No. I was thinking to pack the image in FIT along with ATF and OPTEE like in >> k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for installing the >> firmware. > > In case of our board, that image is not processed by U-Boot (only generated). > Also, processing it from the R5 loader would imply putting remoteproc support > into that level, duplicating what we have in A53 U-Boot. > >> >>> >>>> What benefit would that bring? There are other users of this pattern, e.g. >>>> board/xilinx/zynqmp/pm_cfg_obj.S. >> >> I didn't know U-Boot is accepting this. Tom, is this the preferred way for >> including firmware images? >> >>>> >>> >>> The only benefit of an alternative loading mechanism seems to be handling of >>> larger images from different sources. But that's what I would tackle via boot >>> scripting and, thus, without this feature. If you only have a few hundred bytes >>> to embed, like for k3-rti-wdt, you quickly have a lot of overhead with other >>> approaches. >> >> hmm.. Does the build break if firmware is not present? > > Yes, if you configure to include the firmware but specify an invalid path, the > build breaks. So, how do we handle the travis CI/gitlab build without this firmware. I am not sure how xilinx is handling this. It should be the same case in the above scenario you pointed out. Thanks and regards, Lokesh ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware 2020-06-29 4:54 ` Lokesh Vutla @ 2020-06-29 7:44 ` Jan Kiszka 0 siblings, 0 replies; 27+ messages in thread From: Jan Kiszka @ 2020-06-29 7:44 UTC (permalink / raw) To: u-boot On 29.06.20 06:54, Lokesh Vutla wrote: > > > On 29/06/20 10:20 am, Jan Kiszka wrote: >> On 29.06.20 04:26, Lokesh Vutla wrote: >>> +Tom >>> >>> On 23/06/20 8:11 pm, Jan Kiszka wrote: >>>> On 23.06.20 14:37, Jan Kiszka wrote: >>>>> On 23.06.20 13:50, Lokesh Vutla wrote: >>>>>> >>>>>> >>>>>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>>>> >>>>>>> To avoid the need of extra boot scripting on AM65x for loading a >>>>>>> watchdog firmware, add the required rproc init and loading logic for the >>>>>>> first R5F core to the watchdog start handler. The firmware itself is >>>>>>> embedded into U-Boot binary. >>>>>>> >>>>>>> One possible firmware source is https://github.com/siemens/k3-rti-wdt. >>>>>>> >>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>>>>> --- >>>>>>> ?? drivers/watchdog/Kconfig????? | 20 ++++++++++++++++++++ >>>>>>> ?? drivers/watchdog/Makefile???? |? 3 +++ >>>>>>> ?? drivers/watchdog/rti_wdt.c??? | 24 ++++++++++++++++++++++++ >>>>>>> ?? drivers/watchdog/rti_wdt_fw.S | 20 ++++++++++++++++++++ >>>>>>> ?? 4 files changed, 67 insertions(+) >>>>>>> ?? create mode 100644 drivers/watchdog/rti_wdt_fw.S >>>>>>> >>>>>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >>>>>>> index ee99bd2af1..fd6ab9a85b 100644 >>>>>>> --- a/drivers/watchdog/Kconfig >>>>>>> +++ b/drivers/watchdog/Kconfig >>>>>>> @@ -162,6 +162,26 @@ config WDT_K3_RTI >>>>>>> ???????? Say Y here if you want to include support for the K3 watchdog >>>>>>> ???????? timer (RTI module) available in the K3 generation of processors. >>>>>>> +if WDT_K3_RTI >>>>>>> + >>>>>>> +config WDT_K3_RTI_LOAD_FW >>>>>>> +??? bool "Load watchdog firmware" >>>>>>> +??? depends on REMOTEPROC >>>>>>> +??? help >>>>>>> +????? Automatically load the specified firmware image into the MCU R5F >>>>>>> +????? core 0. On the AM65x, this firmware is supposed to handle the expiry >>>>>>> +????? of the watchdog timer, typically by resetting the system. >>>>>>> + >>>>>>> +config WDT_K3_RTI_FW_FILE >>>>>>> +??? string "Watchdog firmware image file" >>>>>>> +??? default "k3-rti-wdt.fw" >>>>>>> +??? depends on WDT_K3_RTI_LOAD_FW >>>>>>> +??? help >>>>>>> +????? Firmware image to be embedded into U-Boot and loaded on watchdog >>>>>>> +????? start. >>>>>>> + >>>>>>> +endif >>>>>>> + >>>>>>> ?? config WDT_SANDBOX >>>>>>> ?????? bool "Enable Watchdog Timer support for Sandbox" >>>>>>> ?????? depends on SANDBOX && WDT >>>>>>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile >>>>>>> index 16bdbf4970..bf58684875 100644 >>>>>>> --- a/drivers/watchdog/Makefile >>>>>>> +++ b/drivers/watchdog/Makefile >>>>>>> @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o >>>>>>> ?? obj-$(CONFIG_WDT_MTK) += mtk_wdt.o >>>>>>> ?? obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o >>>>>>> ?? obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o >>>>>>> +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o >>>>>>> ?? obj-$(CONFIG_WDT_SP805) += sp805_wdt.o >>>>>>> ?? obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o >>>>>>> ?? obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o >>>>>>> ?? obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o >>>>>>> + >>>>>>> +$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE >>>>>>> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c >>>>>>> index ebe29c7409..38e82a6b6b 100644 >>>>>>> --- a/drivers/watchdog/rti_wdt.c >>>>>>> +++ b/drivers/watchdog/rti_wdt.c >>>>>>> @@ -14,6 +14,7 @@ >>>>>>> ?? #include <power-domain.h> >>>>>>> ?? #include <wdt.h> >>>>>>> ?? #include <asm/io.h> >>>>>>> +#include <remoteproc.h> >>>>>>> ?? /* Timer register set definition */ >>>>>>> ?? #define RTIDWDCTRL??????? 0x90 >>>>>>> @@ -37,11 +38,16 @@ >>>>>>> ?? #define WDT_PRELOAD_MAX??????? 0xfff >>>>>>> +#define RTI_PROC_ID??????? 0 >>>>>> >>>>>> Can we get the rproc id from DT? >>>>> >>>>> You mean, resolve "mcu_r5fss0_core0" to the ID? Doable. >>>>> >>>> >>>> I'm now probing for the first instance of "ti,am654-r5f" compatible. That >>>> excludes usage for the J721E for now, but that one is fine without firmware - >>>> provided there is way to prevent power-down for RTI watchdog otherwise... >>> >>> I was more of thinking to have a DT property to reference R5-core. But anyways, >>> the property is not present in kernel. I am okay with this for now. >>> >>>> >>>>>> >>>>>>> + >>>>>>> ?? struct rti_wdt_priv { >>>>>>> ?????? phys_addr_t regs; >>>>>>> ?????? unsigned int clk_khz; >>>>>>> ?? }; >>>>>>> +extern const u32 rti_wdt_fw[]; >>>>>>> +extern const int rti_wdt_fw_size; >>>>>> >>>>>> FIT is the preferred way of packing images in U-Boot. Can you try using it? >>>>> >>>>> How does that work? Some example for me? >>>>> >>>> >>>> If you happen to refer to fs-loader: That does not target OSPI, our primary use >>>> case. >>> >>> No. I was thinking to pack the image in FIT along with ATF and OPTEE like in >>> k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for installing the >>> firmware. >> >> In case of our board, that image is not processed by U-Boot (only generated). >> Also, processing it from the R5 loader would imply putting remoteproc support >> into that level, duplicating what we have in A53 U-Boot. >> >>> >>>> >>>>> What benefit would that bring? There are other users of this pattern, e.g. >>>>> board/xilinx/zynqmp/pm_cfg_obj.S. >>> >>> I didn't know U-Boot is accepting this. Tom, is this the preferred way for >>> including firmware images? >>> >>>>> >>>> >>>> The only benefit of an alternative loading mechanism seems to be handling of >>>> larger images from different sources. But that's what I would tackle via boot >>>> scripting and, thus, without this feature. If you only have a few hundred bytes >>>> to embed, like for k3-rti-wdt, you quickly have a lot of overhead with other >>>> approaches. >>> >>> hmm.. Does the build break if firmware is not present? >> >> Yes, if you configure to include the firmware but specify an invalid path, the >> build breaks. > > So, how do we handle the travis CI/gitlab build without this firmware. I am not > sure how xilinx is handling this. It should be the same case in the above > scenario you pointed out. You mean some all-yes-config? We could create a dummy image prior to running that build. The Xilinx has its logic disabled when the file name is empty, which is the default. The linker should kick unused bits out then. I can try that as well. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware 2020-06-29 2:26 ` Lokesh Vutla 2020-06-29 4:50 ` Jan Kiszka @ 2020-06-29 12:37 ` Tom Rini 2020-06-29 18:44 ` Jan Kiszka 1 sibling, 1 reply; 27+ messages in thread From: Tom Rini @ 2020-06-29 12:37 UTC (permalink / raw) To: u-boot On Mon, Jun 29, 2020 at 07:56:53AM +0530, Lokesh Vutla wrote: > +Tom > > On 23/06/20 8:11 pm, Jan Kiszka wrote: > > On 23.06.20 14:37, Jan Kiszka wrote: > >> On 23.06.20 13:50, Lokesh Vutla wrote: > >>> > >>> > >>> On 23/06/20 4:45 pm, Jan Kiszka wrote: > >>>> From: Jan Kiszka <jan.kiszka@siemens.com> > >>>> > >>>> To avoid the need of extra boot scripting on AM65x for loading a > >>>> watchdog firmware, add the required rproc init and loading logic for the > >>>> first R5F core to the watchdog start handler. The firmware itself is > >>>> embedded into U-Boot binary. > >>>> > >>>> One possible firmware source is https://github.com/siemens/k3-rti-wdt. > >>>> > >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > >>>> --- > >>>> ? drivers/watchdog/Kconfig????? | 20 ++++++++++++++++++++ > >>>> ? drivers/watchdog/Makefile???? |? 3 +++ > >>>> ? drivers/watchdog/rti_wdt.c??? | 24 ++++++++++++++++++++++++ > >>>> ? drivers/watchdog/rti_wdt_fw.S | 20 ++++++++++++++++++++ > >>>> ? 4 files changed, 67 insertions(+) > >>>> ? create mode 100644 drivers/watchdog/rti_wdt_fw.S > >>>> > >>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > >>>> index ee99bd2af1..fd6ab9a85b 100644 > >>>> --- a/drivers/watchdog/Kconfig > >>>> +++ b/drivers/watchdog/Kconfig > >>>> @@ -162,6 +162,26 @@ config WDT_K3_RTI > >>>> ??????? Say Y here if you want to include support for the K3 watchdog > >>>> ??????? timer (RTI module) available in the K3 generation of processors. > >>>> +if WDT_K3_RTI > >>>> + > >>>> +config WDT_K3_RTI_LOAD_FW > >>>> +??? bool "Load watchdog firmware" > >>>> +??? depends on REMOTEPROC > >>>> +??? help > >>>> +????? Automatically load the specified firmware image into the MCU R5F > >>>> +????? core 0. On the AM65x, this firmware is supposed to handle the expiry > >>>> +????? of the watchdog timer, typically by resetting the system. > >>>> + > >>>> +config WDT_K3_RTI_FW_FILE > >>>> +??? string "Watchdog firmware image file" > >>>> +??? default "k3-rti-wdt.fw" > >>>> +??? depends on WDT_K3_RTI_LOAD_FW > >>>> +??? help > >>>> +????? Firmware image to be embedded into U-Boot and loaded on watchdog > >>>> +????? start. > >>>> + > >>>> +endif > >>>> + > >>>> ? config WDT_SANDBOX > >>>> ????? bool "Enable Watchdog Timer support for Sandbox" > >>>> ????? depends on SANDBOX && WDT > >>>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > >>>> index 16bdbf4970..bf58684875 100644 > >>>> --- a/drivers/watchdog/Makefile > >>>> +++ b/drivers/watchdog/Makefile > >>>> @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o > >>>> ? obj-$(CONFIG_WDT_MTK) += mtk_wdt.o > >>>> ? obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o > >>>> ? obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o > >>>> +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o > >>>> ? obj-$(CONFIG_WDT_SP805) += sp805_wdt.o > >>>> ? obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o > >>>> ? obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o > >>>> ? obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o > >>>> + > >>>> +$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE > >>>> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c > >>>> index ebe29c7409..38e82a6b6b 100644 > >>>> --- a/drivers/watchdog/rti_wdt.c > >>>> +++ b/drivers/watchdog/rti_wdt.c > >>>> @@ -14,6 +14,7 @@ > >>>> ? #include <power-domain.h> > >>>> ? #include <wdt.h> > >>>> ? #include <asm/io.h> > >>>> +#include <remoteproc.h> > >>>> ? /* Timer register set definition */ > >>>> ? #define RTIDWDCTRL??????? 0x90 > >>>> @@ -37,11 +38,16 @@ > >>>> ? #define WDT_PRELOAD_MAX??????? 0xfff > >>>> +#define RTI_PROC_ID??????? 0 > >>> > >>> Can we get the rproc id from DT? > >> > >> You mean, resolve "mcu_r5fss0_core0" to the ID? Doable. > >> > > > > I'm now probing for the first instance of "ti,am654-r5f" compatible. That > > excludes usage for the J721E for now, but that one is fine without firmware - > > provided there is way to prevent power-down for RTI watchdog otherwise... > > I was more of thinking to have a DT property to reference R5-core. But anyways, > the property is not present in kernel. I am okay with this for now. Note that not all properties in a DT in Linux need to be used in Linux, this is something I _think_ there is growing understanding of. > >>>> + > >>>> ? struct rti_wdt_priv { > >>>> ????? phys_addr_t regs; > >>>> ????? unsigned int clk_khz; > >>>> ? }; > >>>> +extern const u32 rti_wdt_fw[]; > >>>> +extern const int rti_wdt_fw_size; > >>> > >>> FIT is the preferred way of packing images in U-Boot. Can you try using it? > >> > >> How does that work? Some example for me? > >> > > > > If you happen to refer to fs-loader: That does not target OSPI, our primary use > > case. > > No. I was thinking to pack the image in FIT along with ATF and OPTEE like in > k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for installing the > firmware. > > > > >> What benefit would that bring? There are other users of this pattern, e.g. > >> board/xilinx/zynqmp/pm_cfg_obj.S. > > I didn't know U-Boot is accepting this. Tom, is this the preferred way for > including firmware images? Adding in Michal. Why is this area doing what it's doing and not one of the other generic ways to handle this problem? Thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200629/ac5a7b82/attachment.sig> ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware 2020-06-29 12:37 ` Tom Rini @ 2020-06-29 18:44 ` Jan Kiszka 2020-07-20 9:36 ` Jan Kiszka 0 siblings, 1 reply; 27+ messages in thread From: Jan Kiszka @ 2020-06-29 18:44 UTC (permalink / raw) To: u-boot On 29.06.20 14:37, Tom Rini wrote: > On Mon, Jun 29, 2020 at 07:56:53AM +0530, Lokesh Vutla wrote: >> +Tom >> >> On 23/06/20 8:11 pm, Jan Kiszka wrote: >>> On 23.06.20 14:37, Jan Kiszka wrote: >>>> On 23.06.20 13:50, Lokesh Vutla wrote: >>>>> >>>>> >>>>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>>> >>>>>> To avoid the need of extra boot scripting on AM65x for loading a >>>>>> watchdog firmware, add the required rproc init and loading logic for the >>>>>> first R5F core to the watchdog start handler. The firmware itself is >>>>>> embedded into U-Boot binary. >>>>>> >>>>>> One possible firmware source is https://github.com/siemens/k3-rti-wdt. >>>>>> >>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>>>> --- >>>>>> ? drivers/watchdog/Kconfig????? | 20 ++++++++++++++++++++ >>>>>> ? drivers/watchdog/Makefile???? |? 3 +++ >>>>>> ? drivers/watchdog/rti_wdt.c??? | 24 ++++++++++++++++++++++++ >>>>>> ? drivers/watchdog/rti_wdt_fw.S | 20 ++++++++++++++++++++ >>>>>> ? 4 files changed, 67 insertions(+) >>>>>> ? create mode 100644 drivers/watchdog/rti_wdt_fw.S >>>>>> >>>>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >>>>>> index ee99bd2af1..fd6ab9a85b 100644 >>>>>> --- a/drivers/watchdog/Kconfig >>>>>> +++ b/drivers/watchdog/Kconfig >>>>>> @@ -162,6 +162,26 @@ config WDT_K3_RTI >>>>>> ??????? Say Y here if you want to include support for the K3 watchdog >>>>>> ??????? timer (RTI module) available in the K3 generation of processors. >>>>>> +if WDT_K3_RTI >>>>>> + >>>>>> +config WDT_K3_RTI_LOAD_FW >>>>>> +??? bool "Load watchdog firmware" >>>>>> +??? depends on REMOTEPROC >>>>>> +??? help >>>>>> +????? Automatically load the specified firmware image into the MCU R5F >>>>>> +????? core 0. On the AM65x, this firmware is supposed to handle the expiry >>>>>> +????? of the watchdog timer, typically by resetting the system. >>>>>> + >>>>>> +config WDT_K3_RTI_FW_FILE >>>>>> +??? string "Watchdog firmware image file" >>>>>> +??? default "k3-rti-wdt.fw" >>>>>> +??? depends on WDT_K3_RTI_LOAD_FW >>>>>> +??? help >>>>>> +????? Firmware image to be embedded into U-Boot and loaded on watchdog >>>>>> +????? start. >>>>>> + >>>>>> +endif >>>>>> + >>>>>> ? config WDT_SANDBOX >>>>>> ????? bool "Enable Watchdog Timer support for Sandbox" >>>>>> ????? depends on SANDBOX && WDT >>>>>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile >>>>>> index 16bdbf4970..bf58684875 100644 >>>>>> --- a/drivers/watchdog/Makefile >>>>>> +++ b/drivers/watchdog/Makefile >>>>>> @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o >>>>>> ? obj-$(CONFIG_WDT_MTK) += mtk_wdt.o >>>>>> ? obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o >>>>>> ? obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o >>>>>> +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o >>>>>> ? obj-$(CONFIG_WDT_SP805) += sp805_wdt.o >>>>>> ? obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o >>>>>> ? obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o >>>>>> ? obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o >>>>>> + >>>>>> +$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE >>>>>> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c >>>>>> index ebe29c7409..38e82a6b6b 100644 >>>>>> --- a/drivers/watchdog/rti_wdt.c >>>>>> +++ b/drivers/watchdog/rti_wdt.c >>>>>> @@ -14,6 +14,7 @@ >>>>>> ? #include <power-domain.h> >>>>>> ? #include <wdt.h> >>>>>> ? #include <asm/io.h> >>>>>> +#include <remoteproc.h> >>>>>> ? /* Timer register set definition */ >>>>>> ? #define RTIDWDCTRL??????? 0x90 >>>>>> @@ -37,11 +38,16 @@ >>>>>> ? #define WDT_PRELOAD_MAX??????? 0xfff >>>>>> +#define RTI_PROC_ID??????? 0 >>>>> >>>>> Can we get the rproc id from DT? >>>> >>>> You mean, resolve "mcu_r5fss0_core0" to the ID? Doable. >>>> >>> >>> I'm now probing for the first instance of "ti,am654-r5f" compatible. That >>> excludes usage for the J721E for now, but that one is fine without firmware - >>> provided there is way to prevent power-down for RTI watchdog otherwise... >> >> I was more of thinking to have a DT property to reference R5-core. But anyways, >> the property is not present in kernel. I am okay with this for now. > > Note that not all properties in a DT in Linux need to be used in Linux, > this is something I _think_ there is growing understanding of. > >>>>>> + >>>>>> ? struct rti_wdt_priv { >>>>>> ????? phys_addr_t regs; >>>>>> ????? unsigned int clk_khz; >>>>>> ? }; >>>>>> +extern const u32 rti_wdt_fw[]; >>>>>> +extern const int rti_wdt_fw_size; >>>>> >>>>> FIT is the preferred way of packing images in U-Boot. Can you try using it? >>>> >>>> How does that work? Some example for me? >>>> >>> >>> If you happen to refer to fs-loader: That does not target OSPI, our primary use >>> case. >> >> No. I was thinking to pack the image in FIT along with ATF and OPTEE like in >> k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for installing the >> firmware. >> >>> >>>> What benefit would that bring? There are other users of this pattern, e.g. >>>> board/xilinx/zynqmp/pm_cfg_obj.S. >> >> I didn't know U-Boot is accepting this. Tom, is this the preferred way for >> including firmware images? > > Adding in Michal. Why is this area doing what it's doing and not one of > the other generic ways to handle this problem? Thanks! > So, what are the recommended "generic ways" for these use cases? Is there a way to stick own stuff into u-boot.itb and get that provided to some handler of U-Boot proper? Seems unlikely. The pattern I found pushes the firmware into the kernel fit image - which is a clear no-go for the watchdog use case because it shall monitor the booting of that very same image (software update case). Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware 2020-06-29 18:44 ` Jan Kiszka @ 2020-07-20 9:36 ` Jan Kiszka 2020-07-21 5:27 ` Lokesh Vutla 0 siblings, 1 reply; 27+ messages in thread From: Jan Kiszka @ 2020-07-20 9:36 UTC (permalink / raw) To: u-boot On 29.06.20 20:44, Jan Kiszka wrote: > On 29.06.20 14:37, Tom Rini wrote: >> On Mon, Jun 29, 2020 at 07:56:53AM +0530, Lokesh Vutla wrote: >>> +Tom >>> >>> On 23/06/20 8:11 pm, Jan Kiszka wrote: >>>> On 23.06.20 14:37, Jan Kiszka wrote: >>>>> On 23.06.20 13:50, Lokesh Vutla wrote: >>>>>> >>>>>> >>>>>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>>>> >>>>>>> To avoid the need of extra boot scripting on AM65x for loading a >>>>>>> watchdog firmware, add the required rproc init and loading logic >>>>>>> for the >>>>>>> first R5F core to the watchdog start handler. The firmware itself is >>>>>>> embedded into U-Boot binary. >>>>>>> >>>>>>> One possible firmware source is >>>>>>> https://github.com/siemens/k3-rti-wdt. >>>>>>> >>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>>>>> --- >>>>>>> ?? drivers/watchdog/Kconfig????? | 20 ++++++++++++++++++++ >>>>>>> ?? drivers/watchdog/Makefile???? |? 3 +++ >>>>>>> ?? drivers/watchdog/rti_wdt.c??? | 24 ++++++++++++++++++++++++ >>>>>>> ?? drivers/watchdog/rti_wdt_fw.S | 20 ++++++++++++++++++++ >>>>>>> ?? 4 files changed, 67 insertions(+) >>>>>>> ?? create mode 100644 drivers/watchdog/rti_wdt_fw.S >>>>>>> >>>>>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >>>>>>> index ee99bd2af1..fd6ab9a85b 100644 >>>>>>> --- a/drivers/watchdog/Kconfig >>>>>>> +++ b/drivers/watchdog/Kconfig >>>>>>> @@ -162,6 +162,26 @@ config WDT_K3_RTI >>>>>>> ???????? Say Y here if you want to include support for the K3 >>>>>>> watchdog >>>>>>> ???????? timer (RTI module) available in the K3 generation of >>>>>>> processors. >>>>>>> +if WDT_K3_RTI >>>>>>> + >>>>>>> +config WDT_K3_RTI_LOAD_FW >>>>>>> +??? bool "Load watchdog firmware" >>>>>>> +??? depends on REMOTEPROC >>>>>>> +??? help >>>>>>> +????? Automatically load the specified firmware image into the >>>>>>> MCU R5F >>>>>>> +????? core 0. On the AM65x, this firmware is supposed to handle >>>>>>> the expiry >>>>>>> +????? of the watchdog timer, typically by resetting the system. >>>>>>> + >>>>>>> +config WDT_K3_RTI_FW_FILE >>>>>>> +??? string "Watchdog firmware image file" >>>>>>> +??? default "k3-rti-wdt.fw" >>>>>>> +??? depends on WDT_K3_RTI_LOAD_FW >>>>>>> +??? help >>>>>>> +????? Firmware image to be embedded into U-Boot and loaded on >>>>>>> watchdog >>>>>>> +????? start. >>>>>>> + >>>>>>> +endif >>>>>>> + >>>>>>> ?? config WDT_SANDBOX >>>>>>> ?????? bool "Enable Watchdog Timer support for Sandbox" >>>>>>> ?????? depends on SANDBOX && WDT >>>>>>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile >>>>>>> index 16bdbf4970..bf58684875 100644 >>>>>>> --- a/drivers/watchdog/Makefile >>>>>>> +++ b/drivers/watchdog/Makefile >>>>>>> @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o >>>>>>> ?? obj-$(CONFIG_WDT_MTK) += mtk_wdt.o >>>>>>> ?? obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o >>>>>>> ?? obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o >>>>>>> +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o >>>>>>> ?? obj-$(CONFIG_WDT_SP805) += sp805_wdt.o >>>>>>> ?? obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o >>>>>>> ?? obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o >>>>>>> ?? obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o >>>>>>> + >>>>>>> +$(obj)/rti_wdt_fw.o: $(shell readlink -f >>>>>>> $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE >>>>>>> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c >>>>>>> index ebe29c7409..38e82a6b6b 100644 >>>>>>> --- a/drivers/watchdog/rti_wdt.c >>>>>>> +++ b/drivers/watchdog/rti_wdt.c >>>>>>> @@ -14,6 +14,7 @@ >>>>>>> ?? #include <power-domain.h> >>>>>>> ?? #include <wdt.h> >>>>>>> ?? #include <asm/io.h> >>>>>>> +#include <remoteproc.h> >>>>>>> ?? /* Timer register set definition */ >>>>>>> ?? #define RTIDWDCTRL??????? 0x90 >>>>>>> @@ -37,11 +38,16 @@ >>>>>>> ?? #define WDT_PRELOAD_MAX??????? 0xfff >>>>>>> +#define RTI_PROC_ID??????? 0 >>>>>> >>>>>> Can we get the rproc id from DT? >>>>> >>>>> You mean, resolve "mcu_r5fss0_core0" to the ID? Doable. >>>>> >>>> >>>> I'm now probing for the first instance of "ti,am654-r5f" compatible. >>>> That >>>> excludes usage for the J721E for now, but that one is fine without >>>> firmware - >>>> provided there is way to prevent power-down for RTI watchdog >>>> otherwise... >>> >>> I was more of thinking to have a DT property to reference R5-core. >>> But anyways, >>> the property is not present in kernel. I am okay with this for now. >> >> Note that not all properties in a DT in Linux need to be used in Linux, >> this is something I _think_ there is growing understanding of. >> >>>>>>> + >>>>>>> ?? struct rti_wdt_priv { >>>>>>> ?????? phys_addr_t regs; >>>>>>> ?????? unsigned int clk_khz; >>>>>>> ?? }; >>>>>>> +extern const u32 rti_wdt_fw[]; >>>>>>> +extern const int rti_wdt_fw_size; >>>>>> >>>>>> FIT is the preferred way of packing images in U-Boot. Can you try >>>>>> using it? >>>>> >>>>> How does that work? Some example for me? >>>>> >>>> >>>> If you happen to refer to fs-loader: That does not target OSPI, our >>>> primary use >>>> case. >>> >>> No. I was thinking to pack the image in FIT along with ATF and OPTEE >>> like in >>> k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for >>> installing the >>> firmware. >>> >>>> >>>>> What benefit would that bring? There are other users of this >>>>> pattern, e.g. >>>>> board/xilinx/zynqmp/pm_cfg_obj.S. >>> >>> I didn't know U-Boot is accepting this. Tom, is this the preferred >>> way for >>> including firmware images? >> >> Adding in Michal.? Why is this area doing what it's doing and not one of >> the other generic ways to handle this problem?? Thanks! >> > > So, what are the recommended "generic ways" for these use cases? > > Is there a way to stick own stuff into u-boot.itb and get that provided > to some handler of U-Boot proper? Seems unlikely. The pattern I found > pushes the firmware into the kernel fit image - which is a clear no-go > for the watchdog use case because it shall monitor the booting of that > very same image (software update case). > > Jan > Ping on this. I'd like to move forward with this series. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware 2020-07-20 9:36 ` Jan Kiszka @ 2020-07-21 5:27 ` Lokesh Vutla 2020-07-21 6:26 ` Jan Kiszka 0 siblings, 1 reply; 27+ messages in thread From: Lokesh Vutla @ 2020-07-21 5:27 UTC (permalink / raw) To: u-boot Hi Jan, On 20/07/20 3:06 pm, Jan Kiszka wrote: > On 29.06.20 20:44, Jan Kiszka wrote: >> On 29.06.20 14:37, Tom Rini wrote: >>> On Mon, Jun 29, 2020 at 07:56:53AM +0530, Lokesh Vutla wrote: >>>> +Tom >>>> >>>> On 23/06/20 8:11 pm, Jan Kiszka wrote: >>>>> On 23.06.20 14:37, Jan Kiszka wrote: >>>>>> On 23.06.20 13:50, Lokesh Vutla wrote: >>>>>>> >>>>>>> >>>>>>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>>>>> >>>>>>>> To avoid the need of extra boot scripting on AM65x for loading a >>>>>>>> watchdog firmware, add the required rproc init and loading logic for the >>>>>>>> first R5F core to the watchdog start handler. The firmware itself is >>>>>>>> embedded into U-Boot binary. >>>>>>>> >>>>>>>> One possible firmware source is https://github.com/siemens/k3-rti-wdt. >>>>>>>> >>>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>>>>>> --- >>>>>>>> ?? drivers/watchdog/Kconfig????? | 20 ++++++++++++++++++++ >>>>>>>> ?? drivers/watchdog/Makefile???? |? 3 +++ >>>>>>>> ?? drivers/watchdog/rti_wdt.c??? | 24 ++++++++++++++++++++++++ >>>>>>>> ?? drivers/watchdog/rti_wdt_fw.S | 20 ++++++++++++++++++++ >>>>>>>> ?? 4 files changed, 67 insertions(+) >>>>>>>> ?? create mode 100644 drivers/watchdog/rti_wdt_fw.S >>>>>>>> >>>>>>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >>>>>>>> index ee99bd2af1..fd6ab9a85b 100644 >>>>>>>> --- a/drivers/watchdog/Kconfig >>>>>>>> +++ b/drivers/watchdog/Kconfig >>>>>>>> @@ -162,6 +162,26 @@ config WDT_K3_RTI >>>>>>>> ???????? Say Y here if you want to include support for the K3 watchdog >>>>>>>> ???????? timer (RTI module) available in the K3 generation of processors. >>>>>>>> +if WDT_K3_RTI >>>>>>>> + >>>>>>>> +config WDT_K3_RTI_LOAD_FW >>>>>>>> +??? bool "Load watchdog firmware" >>>>>>>> +??? depends on REMOTEPROC >>>>>>>> +??? help >>>>>>>> +????? Automatically load the specified firmware image into the MCU R5F >>>>>>>> +????? core 0. On the AM65x, this firmware is supposed to handle the expiry >>>>>>>> +????? of the watchdog timer, typically by resetting the system. >>>>>>>> + >>>>>>>> +config WDT_K3_RTI_FW_FILE >>>>>>>> +??? string "Watchdog firmware image file" >>>>>>>> +??? default "k3-rti-wdt.fw" >>>>>>>> +??? depends on WDT_K3_RTI_LOAD_FW >>>>>>>> +??? help >>>>>>>> +????? Firmware image to be embedded into U-Boot and loaded on watchdog >>>>>>>> +????? start. >>>>>>>> + >>>>>>>> +endif >>>>>>>> + >>>>>>>> ?? config WDT_SANDBOX >>>>>>>> ?????? bool "Enable Watchdog Timer support for Sandbox" >>>>>>>> ?????? depends on SANDBOX && WDT >>>>>>>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile >>>>>>>> index 16bdbf4970..bf58684875 100644 >>>>>>>> --- a/drivers/watchdog/Makefile >>>>>>>> +++ b/drivers/watchdog/Makefile >>>>>>>> @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o >>>>>>>> ?? obj-$(CONFIG_WDT_MTK) += mtk_wdt.o >>>>>>>> ?? obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o >>>>>>>> ?? obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o >>>>>>>> +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o >>>>>>>> ?? obj-$(CONFIG_WDT_SP805) += sp805_wdt.o >>>>>>>> ?? obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o >>>>>>>> ?? obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o >>>>>>>> ?? obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o >>>>>>>> + >>>>>>>> +$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) >>>>>>>> FORCE >>>>>>>> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c >>>>>>>> index ebe29c7409..38e82a6b6b 100644 >>>>>>>> --- a/drivers/watchdog/rti_wdt.c >>>>>>>> +++ b/drivers/watchdog/rti_wdt.c >>>>>>>> @@ -14,6 +14,7 @@ >>>>>>>> ?? #include <power-domain.h> >>>>>>>> ?? #include <wdt.h> >>>>>>>> ?? #include <asm/io.h> >>>>>>>> +#include <remoteproc.h> >>>>>>>> ?? /* Timer register set definition */ >>>>>>>> ?? #define RTIDWDCTRL??????? 0x90 >>>>>>>> @@ -37,11 +38,16 @@ >>>>>>>> ?? #define WDT_PRELOAD_MAX??????? 0xfff >>>>>>>> +#define RTI_PROC_ID??????? 0 >>>>>>> >>>>>>> Can we get the rproc id from DT? >>>>>> >>>>>> You mean, resolve "mcu_r5fss0_core0" to the ID? Doable. >>>>>> >>>>> >>>>> I'm now probing for the first instance of "ti,am654-r5f" compatible. That >>>>> excludes usage for the J721E for now, but that one is fine without firmware - >>>>> provided there is way to prevent power-down for RTI watchdog otherwise... >>>> >>>> I was more of thinking to have a DT property to reference R5-core. But anyways, >>>> the property is not present in kernel. I am okay with this for now. >>> >>> Note that not all properties in a DT in Linux need to be used in Linux, >>> this is something I _think_ there is growing understanding of. >>> >>>>>>>> + >>>>>>>> ?? struct rti_wdt_priv { >>>>>>>> ?????? phys_addr_t regs; >>>>>>>> ?????? unsigned int clk_khz; >>>>>>>> ?? }; >>>>>>>> +extern const u32 rti_wdt_fw[]; >>>>>>>> +extern const int rti_wdt_fw_size; >>>>>>> >>>>>>> FIT is the preferred way of packing images in U-Boot. Can you try using it? >>>>>> >>>>>> How does that work? Some example for me? >>>>>> >>>>> >>>>> If you happen to refer to fs-loader: That does not target OSPI, our primary >>>>> use >>>>> case. >>>> >>>> No. I was thinking to pack the image in FIT along with ATF and OPTEE like in >>>> k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for installing the >>>> firmware. >>>> >>>>> >>>>>> What benefit would that bring? There are other users of this pattern, e.g. >>>>>> board/xilinx/zynqmp/pm_cfg_obj.S. >>>> >>>> I didn't know U-Boot is accepting this. Tom, is this the preferred way for >>>> including firmware images? >>> >>> Adding in Michal.? Why is this area doing what it's doing and not one of >>> the other generic ways to handle this problem?? Thanks! >>> >> >> So, what are the recommended "generic ways" for these use cases? >> >> Is there a way to stick own stuff into u-boot.itb and get that provided to >> some handler of U-Boot proper? Seems unlikely. The pattern I found pushes the >> firmware into the kernel fit image - which is a clear no-go for the watchdog >> use case because it shall monitor the booting of that very same image >> (software update case). >> >> Jan >> > > Ping on this. I'd like to move forward with this series. If you want remotecore to be loaded early, then my preference would be to pack Firmware inside FIT image(along with A72 SPL, ATF or A72 U-Boot) as loadable and register a handle to load and start the rproc in SPL. If it can be delayed, I prefer to do at U-Boot prompt. However, the driver can be merged separately. If you can re post the driver part I can pull it in soon. Thanks and regards, Lokesh ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware 2020-07-21 5:27 ` Lokesh Vutla @ 2020-07-21 6:26 ` Jan Kiszka 0 siblings, 0 replies; 27+ messages in thread From: Jan Kiszka @ 2020-07-21 6:26 UTC (permalink / raw) To: u-boot On 21.07.20 07:27, Lokesh Vutla wrote: > Hi Jan, > > On 20/07/20 3:06 pm, Jan Kiszka wrote: >> On 29.06.20 20:44, Jan Kiszka wrote: >>> On 29.06.20 14:37, Tom Rini wrote: >>>> On Mon, Jun 29, 2020 at 07:56:53AM +0530, Lokesh Vutla wrote: >>>>> +Tom >>>>> >>>>> On 23/06/20 8:11 pm, Jan Kiszka wrote: >>>>>> On 23.06.20 14:37, Jan Kiszka wrote: >>>>>>> On 23.06.20 13:50, Lokesh Vutla wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>>>>>> >>>>>>>>> To avoid the need of extra boot scripting on AM65x for loading a >>>>>>>>> watchdog firmware, add the required rproc init and loading logic for the >>>>>>>>> first R5F core to the watchdog start handler. The firmware itself is >>>>>>>>> embedded into U-Boot binary. >>>>>>>>> >>>>>>>>> One possible firmware source is https://github.com/siemens/k3-rti-wdt. >>>>>>>>> >>>>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>>>>>>> --- >>>>>>>>> ?? drivers/watchdog/Kconfig????? | 20 ++++++++++++++++++++ >>>>>>>>> ?? drivers/watchdog/Makefile???? |? 3 +++ >>>>>>>>> ?? drivers/watchdog/rti_wdt.c??? | 24 ++++++++++++++++++++++++ >>>>>>>>> ?? drivers/watchdog/rti_wdt_fw.S | 20 ++++++++++++++++++++ >>>>>>>>> ?? 4 files changed, 67 insertions(+) >>>>>>>>> ?? create mode 100644 drivers/watchdog/rti_wdt_fw.S >>>>>>>>> >>>>>>>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >>>>>>>>> index ee99bd2af1..fd6ab9a85b 100644 >>>>>>>>> --- a/drivers/watchdog/Kconfig >>>>>>>>> +++ b/drivers/watchdog/Kconfig >>>>>>>>> @@ -162,6 +162,26 @@ config WDT_K3_RTI >>>>>>>>> ???????? Say Y here if you want to include support for the K3 watchdog >>>>>>>>> ???????? timer (RTI module) available in the K3 generation of processors. >>>>>>>>> +if WDT_K3_RTI >>>>>>>>> + >>>>>>>>> +config WDT_K3_RTI_LOAD_FW >>>>>>>>> +??? bool "Load watchdog firmware" >>>>>>>>> +??? depends on REMOTEPROC >>>>>>>>> +??? help >>>>>>>>> +????? Automatically load the specified firmware image into the MCU R5F >>>>>>>>> +????? core 0. On the AM65x, this firmware is supposed to handle the expiry >>>>>>>>> +????? of the watchdog timer, typically by resetting the system. >>>>>>>>> + >>>>>>>>> +config WDT_K3_RTI_FW_FILE >>>>>>>>> +??? string "Watchdog firmware image file" >>>>>>>>> +??? default "k3-rti-wdt.fw" >>>>>>>>> +??? depends on WDT_K3_RTI_LOAD_FW >>>>>>>>> +??? help >>>>>>>>> +????? Firmware image to be embedded into U-Boot and loaded on watchdog >>>>>>>>> +????? start. >>>>>>>>> + >>>>>>>>> +endif >>>>>>>>> + >>>>>>>>> ?? config WDT_SANDBOX >>>>>>>>> ?????? bool "Enable Watchdog Timer support for Sandbox" >>>>>>>>> ?????? depends on SANDBOX && WDT >>>>>>>>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile >>>>>>>>> index 16bdbf4970..bf58684875 100644 >>>>>>>>> --- a/drivers/watchdog/Makefile >>>>>>>>> +++ b/drivers/watchdog/Makefile >>>>>>>>> @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o >>>>>>>>> ?? obj-$(CONFIG_WDT_MTK) += mtk_wdt.o >>>>>>>>> ?? obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o >>>>>>>>> ?? obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o >>>>>>>>> +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o >>>>>>>>> ?? obj-$(CONFIG_WDT_SP805) += sp805_wdt.o >>>>>>>>> ?? obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o >>>>>>>>> ?? obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o >>>>>>>>> ?? obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o >>>>>>>>> + >>>>>>>>> +$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) >>>>>>>>> FORCE >>>>>>>>> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c >>>>>>>>> index ebe29c7409..38e82a6b6b 100644 >>>>>>>>> --- a/drivers/watchdog/rti_wdt.c >>>>>>>>> +++ b/drivers/watchdog/rti_wdt.c >>>>>>>>> @@ -14,6 +14,7 @@ >>>>>>>>> ?? #include <power-domain.h> >>>>>>>>> ?? #include <wdt.h> >>>>>>>>> ?? #include <asm/io.h> >>>>>>>>> +#include <remoteproc.h> >>>>>>>>> ?? /* Timer register set definition */ >>>>>>>>> ?? #define RTIDWDCTRL??????? 0x90 >>>>>>>>> @@ -37,11 +38,16 @@ >>>>>>>>> ?? #define WDT_PRELOAD_MAX??????? 0xfff >>>>>>>>> +#define RTI_PROC_ID??????? 0 >>>>>>>> >>>>>>>> Can we get the rproc id from DT? >>>>>>> >>>>>>> You mean, resolve "mcu_r5fss0_core0" to the ID? Doable. >>>>>>> >>>>>> >>>>>> I'm now probing for the first instance of "ti,am654-r5f" compatible. That >>>>>> excludes usage for the J721E for now, but that one is fine without firmware - >>>>>> provided there is way to prevent power-down for RTI watchdog otherwise... >>>>> >>>>> I was more of thinking to have a DT property to reference R5-core. But anyways, >>>>> the property is not present in kernel. I am okay with this for now. >>>> >>>> Note that not all properties in a DT in Linux need to be used in Linux, >>>> this is something I _think_ there is growing understanding of. >>>> >>>>>>>>> + >>>>>>>>> ?? struct rti_wdt_priv { >>>>>>>>> ?????? phys_addr_t regs; >>>>>>>>> ?????? unsigned int clk_khz; >>>>>>>>> ?? }; >>>>>>>>> +extern const u32 rti_wdt_fw[]; >>>>>>>>> +extern const int rti_wdt_fw_size; >>>>>>>> >>>>>>>> FIT is the preferred way of packing images in U-Boot. Can you try using it? >>>>>>> >>>>>>> How does that work? Some example for me? >>>>>>> >>>>>> >>>>>> If you happen to refer to fs-loader: That does not target OSPI, our primary >>>>>> use >>>>>> case. >>>>> >>>>> No. I was thinking to pack the image in FIT along with ATF and OPTEE like in >>>>> k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for installing the >>>>> firmware. >>>>> >>>>>> >>>>>>> What benefit would that bring? There are other users of this pattern, e.g. >>>>>>> board/xilinx/zynqmp/pm_cfg_obj.S. >>>>> >>>>> I didn't know U-Boot is accepting this. Tom, is this the preferred way for >>>>> including firmware images? >>>> >>>> Adding in Michal.? Why is this area doing what it's doing and not one of >>>> the other generic ways to handle this problem?? Thanks! >>>> >>> >>> So, what are the recommended "generic ways" for these use cases? >>> >>> Is there a way to stick own stuff into u-boot.itb and get that provided to >>> some handler of U-Boot proper? Seems unlikely. The pattern I found pushes the >>> firmware into the kernel fit image - which is a clear no-go for the watchdog >>> use case because it shall monitor the booting of that very same image >>> (software update case). >>> >>> Jan >>> >> >> Ping on this. I'd like to move forward with this series. > > If you want remotecore to be loaded early, then my preference would be to pack > Firmware inside FIT image(along with A72 SPL, ATF or A72 U-Boot) as loadable and > register a handle to load and start the rproc in SPL. If it can be delayed, I > prefer to do at U-Boot prompt. > So far, we do not need it in SPL as we have no procedure to update U-Boot proper safely. Moving things to SPL would imply carrying the remoteproc infrastructure twice. For loading from the prompt, we are still lacking a handy way to bundle the firmware with the integrity-checked U-Boot proper. Yes, technically I could push those 676 bytes into a fitimage, sign it, reserve a block in SPI flash or some other storage, load it from there and validate it. But that's overkill IMHO. > > However, the driver can be merged separately. If you can re post the driver part > I can pull it in soon. You could cherry-pick patch 1 and 3 for that already, they still apply. Thanks, Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 3/3] arm: dts: k3: Add RTI watchdogs 2020-06-23 11:15 [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support Jan Kiszka 2020-06-23 11:15 ` [PATCH v2 1/3] watchdog: Add support for K3 RTI watchdog Jan Kiszka 2020-06-23 11:15 ` [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware Jan Kiszka @ 2020-06-23 11:15 ` Jan Kiszka 2020-08-11 10:33 ` [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support Lokesh Vutla 3 siblings, 0 replies; 27+ messages in thread From: Jan Kiszka @ 2020-06-23 11:15 UTC (permalink / raw) To: u-boot From: Jan Kiszka <jan.kiszka@siemens.com> Add DT entries for main domain watchdog0 and 1 instances on the J721e well as RTI1-based watchdog on the AM65x. RTI0 does not work for this purpose on the AM65x, so leave it out. On AM65x, we mark the power-domain as shared because RTI firmware such as https://github.com/siemens/k3-rti-wdt may request it as well in order to prevent accidental shutdown of the watchdog. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- arch/arm/dts/k3-am65-mcu.dtsi | 9 +++++++++ arch/arm/dts/k3-j721e-main.dtsi | 18 ++++++++++++++++++ 2 files changed, 27 insertions(+) diff --git a/arch/arm/dts/k3-am65-mcu.dtsi b/arch/arm/dts/k3-am65-mcu.dtsi index bc9a87210d..6498dcdae4 100644 --- a/arch/arm/dts/k3-am65-mcu.dtsi +++ b/arch/arm/dts/k3-am65-mcu.dtsi @@ -102,4 +102,13 @@ #size-cells = <0>; }; }; + + mcu_rti1: rti at 40610000 { + compatible = "ti,j7-rti-wdt"; + reg = <0x0 0x40610000 0x0 0x100>; + clocks = <&k3_clks 135 0>; + power-domains = <&k3_pds 135 TI_SCI_PD_SHARED>; + assigned-clocks = <&k3_clks 135 0>; + assigned-clock-parents = <&k3_clks 135 4>; + }; }; diff --git a/arch/arm/dts/k3-j721e-main.dtsi b/arch/arm/dts/k3-j721e-main.dtsi index 1433932e7f..a285b1afa8 100644 --- a/arch/arm/dts/k3-j721e-main.dtsi +++ b/arch/arm/dts/k3-j721e-main.dtsi @@ -543,4 +543,22 @@ clocks = <&k3_clks 193 0>; power-domains = <&k3_pds 193 TI_SCI_PD_EXCLUSIVE>; }; + + watchdog0: watchdog at 2200000 { + compatible = "ti,j7-rti-wdt"; + reg = <0x0 0x2200000 0x0 0x100>; + clocks = <&k3_clks 252 1>; + power-domains = <&k3_pds 252 TI_SCI_PD_EXCLUSIVE>; + assigned-clocks = <&k3_clks 252 1>; + assigned-clock-parents = <&k3_clks 252 5>; + }; + + watchdog1: watchdog at 2210000 { + compatible = "ti,j7-rti-wdt"; + reg = <0x0 0x2210000 0x0 0x100>; + clocks = <&k3_clks 253 1>; + power-domains = <&k3_pds 253 TI_SCI_PD_EXCLUSIVE>; + assigned-clocks = <&k3_clks 253 1>; + assigned-clock-parents = <&k3_clks 253 5>; + }; }; -- 2.26.2 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support 2020-06-23 11:15 [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support Jan Kiszka ` (2 preceding siblings ...) 2020-06-23 11:15 ` [PATCH v2 3/3] arm: dts: k3: Add RTI watchdogs Jan Kiszka @ 2020-08-11 10:33 ` Lokesh Vutla 2020-08-11 10:42 ` Jan Kiszka 3 siblings, 1 reply; 27+ messages in thread From: Lokesh Vutla @ 2020-08-11 10:33 UTC (permalink / raw) To: u-boot On 23/06/20 4:45 pm, Jan Kiszka wrote: > This brings watchdog support for the TI K3 SoCs, derived from the Linux > kernel, augmented with firmware loading as needed on the AM65x. > > Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream > support will be posted soon). > > Changes in v2: > - keep watchdog powered when handing over to Linux > - drop unneeded explicit power-on > - account for RTI firmware locking the power domain Patch 1 and 3 merged applied. Thanks and regards, Lokesh ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support 2020-08-11 10:33 ` [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support Lokesh Vutla @ 2020-08-11 10:42 ` Jan Kiszka 2020-08-11 10:46 ` Lokesh Vutla 0 siblings, 1 reply; 27+ messages in thread From: Jan Kiszka @ 2020-08-11 10:42 UTC (permalink / raw) To: u-boot On 11.08.20 12:33, Lokesh Vutla wrote: > > > On 23/06/20 4:45 pm, Jan Kiszka wrote: >> This brings watchdog support for the TI K3 SoCs, derived from the Linux >> kernel, augmented with firmware loading as needed on the AM65x. >> >> Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream >> support will be posted soon). >> >> Changes in v2: >> - keep watchdog powered when handing over to Linux >> - drop unneeded explicit power-on >> - account for RTI firmware locking the power domain > > Patch 1 and 3 merged applied. > Thanks. Still taking workable suggestions for loading the firmware. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support 2020-08-11 10:42 ` Jan Kiszka @ 2020-08-11 10:46 ` Lokesh Vutla 2020-08-11 12:37 ` Jan Kiszka 0 siblings, 1 reply; 27+ messages in thread From: Lokesh Vutla @ 2020-08-11 10:46 UTC (permalink / raw) To: u-boot On 11/08/20 4:12 pm, Jan Kiszka wrote: > On 11.08.20 12:33, Lokesh Vutla wrote: >> >> >> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>> This brings watchdog support for the TI K3 SoCs, derived from the Linux >>> kernel, augmented with firmware loading as needed on the AM65x. >>> >>> Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream >>> support will be posted soon). >>> >>> Changes in v2: >>> ? - keep watchdog powered when handing over to Linux >>> ? - drop unneeded explicit power-on >>> ? - account for RTI firmware locking the power domain >> >> Patch 1 and 3 merged applied. >> > > Thanks. Still taking workable suggestions for loading the firmware. FIT image is the one that I can think off. Since SPL is loading the FIT image, SPL_HANDOFF can be used to pass on the loadaddr from SPL to U-Boot and U-Boot can start the remote cores using this info. Thanks and regards, Lokesh ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support 2020-08-11 10:46 ` Lokesh Vutla @ 2020-08-11 12:37 ` Jan Kiszka 2020-08-11 14:36 ` Lokesh Vutla 0 siblings, 1 reply; 27+ messages in thread From: Jan Kiszka @ 2020-08-11 12:37 UTC (permalink / raw) To: u-boot On 11.08.20 12:46, Lokesh Vutla wrote: > > > On 11/08/20 4:12 pm, Jan Kiszka wrote: >> On 11.08.20 12:33, Lokesh Vutla wrote: >>> >>> >>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>> This brings watchdog support for the TI K3 SoCs, derived from the Linux >>>> kernel, augmented with firmware loading as needed on the AM65x. >>>> >>>> Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream >>>> support will be posted soon). >>>> >>>> Changes in v2: >>>> ? - keep watchdog powered when handing over to Linux >>>> ? - drop unneeded explicit power-on >>>> ? - account for RTI firmware locking the power domain >>> >>> Patch 1 and 3 merged applied. >>> >> >> Thanks. Still taking workable suggestions for loading the firmware. > > FIT image is the one that I can think off. Since SPL is loading the FIT image, > SPL_HANDOFF can be used to pass on the loadaddr from SPL to U-Boot and U-Boot > can start the remote cores using this info. OK, just the ensure I got the idea correctly: - extend struct spl_handoff or arch_spl_handoff with the fit image loadaddr that spl is processing - stick the watchdog firmware into the u-boot proper fit image (generated by tools/k3_fit_atf.sh or shipped via the board folder, as in our case) - from the watchdog driver, trigger parsing of that fit image and extracting of the firmware from there Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support 2020-08-11 12:37 ` Jan Kiszka @ 2020-08-11 14:36 ` Lokesh Vutla 2020-08-11 14:58 ` Jan Kiszka 0 siblings, 1 reply; 27+ messages in thread From: Lokesh Vutla @ 2020-08-11 14:36 UTC (permalink / raw) To: u-boot Hi Jan, On 11/08/20 6:07 pm, Jan Kiszka wrote: > On 11.08.20 12:46, Lokesh Vutla wrote: >> >> >> On 11/08/20 4:12 pm, Jan Kiszka wrote: >>> On 11.08.20 12:33, Lokesh Vutla wrote: >>>> >>>> >>>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>>> This brings watchdog support for the TI K3 SoCs, derived from the Linux >>>>> kernel, augmented with firmware loading as needed on the AM65x. >>>>> >>>>> Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream >>>>> support will be posted soon). >>>>> >>>>> Changes in v2: >>>>> ?? - keep watchdog powered when handing over to Linux >>>>> ?? - drop unneeded explicit power-on >>>>> ?? - account for RTI firmware locking the power domain >>>> >>>> Patch 1 and 3 merged applied. >>>> >>> >>> Thanks. Still taking workable suggestions for loading the firmware. >> >> FIT image is the one that I can think off. Since SPL is loading the FIT image, >> SPL_HANDOFF can be used to pass on the loadaddr from SPL to U-Boot and U-Boot >> can start the remote cores using this info. > > OK, just the ensure I got the idea correctly: > > ?- extend struct spl_handoff or arch_spl_handoff with the fit image > ?? loadaddr that spl is processing Yes > > ?- stick the watchdog firmware into the u-boot proper fit image > ?? (generated by tools/k3_fit_atf.sh or shipped via the board folder, as > ?? in our case) IMHO, not via board folder. k3_fit_atf is used to generate a53 spl images. May be create a new one that packs fit image with u-boot and firmware. Or can you check if binman in u-boot works for you? > > ?- from the watchdog driver, trigger parsing of that fit image and > ?? extracting of the firmware from there Yes Thanks and regards, Lokesh > > Jan > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support 2020-08-11 14:36 ` Lokesh Vutla @ 2020-08-11 14:58 ` Jan Kiszka 2020-08-11 18:01 ` Lokesh Vutla 0 siblings, 1 reply; 27+ messages in thread From: Jan Kiszka @ 2020-08-11 14:58 UTC (permalink / raw) To: u-boot On 11.08.20 16:36, Lokesh Vutla wrote: > Hi Jan, > > On 11/08/20 6:07 pm, Jan Kiszka wrote: >> On 11.08.20 12:46, Lokesh Vutla wrote: >>> >>> >>> On 11/08/20 4:12 pm, Jan Kiszka wrote: >>>> On 11.08.20 12:33, Lokesh Vutla wrote: >>>>> >>>>> >>>>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>>>> This brings watchdog support for the TI K3 SoCs, derived from the Linux >>>>>> kernel, augmented with firmware loading as needed on the AM65x. >>>>>> >>>>>> Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream >>>>>> support will be posted soon). >>>>>> >>>>>> Changes in v2: >>>>>> ?? - keep watchdog powered when handing over to Linux >>>>>> ?? - drop unneeded explicit power-on >>>>>> ?? - account for RTI firmware locking the power domain >>>>> >>>>> Patch 1 and 3 merged applied. >>>>> >>>> >>>> Thanks. Still taking workable suggestions for loading the firmware. >>> >>> FIT image is the one that I can think off. Since SPL is loading the FIT image, >>> SPL_HANDOFF can be used to pass on the loadaddr from SPL to U-Boot and U-Boot >>> can start the remote cores using this info. >> >> OK, just the ensure I got the idea correctly: >> >> ?- extend struct spl_handoff or arch_spl_handoff with the fit image >> ?? loadaddr that spl is processing > > Yes > >> >> ?- stick the watchdog firmware into the u-boot proper fit image >> ?? (generated by tools/k3_fit_atf.sh or shipped via the board folder, as >> ?? in our case) > > IMHO, not via board folder. k3_fit_atf is used to generate a53 spl images. May Yeah, right. We also have a fit image for u-boot proper, that confused me. > be create a new one that packs fit image with u-boot and firmware. Or can you > check if binman in u-boot works for you? You mean, pack the u-boot proper with the firmware? Then we could stick the result in an signed fit image when needed. And I could read the offset of the firmware from the generated dtb - provided binman can deal with multiple configurations like we have. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support 2020-08-11 14:58 ` Jan Kiszka @ 2020-08-11 18:01 ` Lokesh Vutla 2020-08-13 12:12 ` Jan Kiszka 0 siblings, 1 reply; 27+ messages in thread From: Lokesh Vutla @ 2020-08-11 18:01 UTC (permalink / raw) To: u-boot On 11/08/20 8:28 pm, Jan Kiszka wrote: > On 11.08.20 16:36, Lokesh Vutla wrote: >> Hi Jan, >> >> On 11/08/20 6:07 pm, Jan Kiszka wrote: >>> On 11.08.20 12:46, Lokesh Vutla wrote: >>>> >>>> >>>> On 11/08/20 4:12 pm, Jan Kiszka wrote: >>>>> On 11.08.20 12:33, Lokesh Vutla wrote: >>>>>> >>>>>> >>>>>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>>>>> This brings watchdog support for the TI K3 SoCs, derived from the Linux >>>>>>> kernel, augmented with firmware loading as needed on the AM65x. >>>>>>> >>>>>>> Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream >>>>>>> support will be posted soon). >>>>>>> >>>>>>> Changes in v2: >>>>>>> ??? - keep watchdog powered when handing over to Linux >>>>>>> ??? - drop unneeded explicit power-on >>>>>>> ??? - account for RTI firmware locking the power domain >>>>>> >>>>>> Patch 1 and 3 merged applied. >>>>>> >>>>> >>>>> Thanks. Still taking workable suggestions for loading the firmware. >>>> >>>> FIT image is the one that I can think off. Since SPL is loading the FIT image, >>>> SPL_HANDOFF can be used to pass on the loadaddr from SPL to U-Boot and U-Boot >>>> can start the remote cores using this info. >>> >>> OK, just the ensure I got the idea correctly: >>> >>> ??- extend struct spl_handoff or arch_spl_handoff with the fit image >>> ??? loadaddr that spl is processing >> >> Yes >> >>> >>> ??- stick the watchdog firmware into the u-boot proper fit image >>> ??? (generated by tools/k3_fit_atf.sh or shipped via the board folder, as >>> ??? in our case) >> >> IMHO, not via board folder. k3_fit_atf is used to generate a53 spl images. May > > Yeah, right. We also have a fit image for u-boot proper, that confused me. > >> be create a new one that packs fit image with u-boot and firmware. Or can you >> check if binman in u-boot works for you? > > You mean, pack the u-boot proper with the firmware? Then we could stick the > result in an signed fit image when needed. And I could read the offset of the > firmware from the generated dtb - provided binman can deal with multiple > configurations like we have. If that is possible I am okay with it. Thanks and regards, Lokesh > > Jan > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support 2020-08-11 18:01 ` Lokesh Vutla @ 2020-08-13 12:12 ` Jan Kiszka 2020-08-17 11:31 ` Jan Kiszka 0 siblings, 1 reply; 27+ messages in thread From: Jan Kiszka @ 2020-08-13 12:12 UTC (permalink / raw) To: u-boot On 11.08.20 20:01, Lokesh Vutla wrote: > > > On 11/08/20 8:28 pm, Jan Kiszka wrote: >> On 11.08.20 16:36, Lokesh Vutla wrote: >>> Hi Jan, >>> >>> On 11/08/20 6:07 pm, Jan Kiszka wrote: >>>> On 11.08.20 12:46, Lokesh Vutla wrote: >>>>> >>>>> >>>>> On 11/08/20 4:12 pm, Jan Kiszka wrote: >>>>>> On 11.08.20 12:33, Lokesh Vutla wrote: >>>>>>> >>>>>>> >>>>>>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>>>>>> This brings watchdog support for the TI K3 SoCs, derived from the Linux >>>>>>>> kernel, augmented with firmware loading as needed on the AM65x. >>>>>>>> >>>>>>>> Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream >>>>>>>> support will be posted soon). >>>>>>>> >>>>>>>> Changes in v2: >>>>>>>> ??? - keep watchdog powered when handing over to Linux >>>>>>>> ??? - drop unneeded explicit power-on >>>>>>>> ??? - account for RTI firmware locking the power domain >>>>>>> >>>>>>> Patch 1 and 3 merged applied. >>>>>>> >>>>>> >>>>>> Thanks. Still taking workable suggestions for loading the firmware. >>>>> >>>>> FIT image is the one that I can think off. Since SPL is loading the FIT image, >>>>> SPL_HANDOFF can be used to pass on the loadaddr from SPL to U-Boot and U-Boot >>>>> can start the remote cores using this info. >>>> >>>> OK, just the ensure I got the idea correctly: >>>> >>>> ??- extend struct spl_handoff or arch_spl_handoff with the fit image >>>> ??? loadaddr that spl is processing >>> >>> Yes >>> >>>> >>>> ??- stick the watchdog firmware into the u-boot proper fit image >>>> ??? (generated by tools/k3_fit_atf.sh or shipped via the board folder, as >>>> ??? in our case) >>> >>> IMHO, not via board folder. k3_fit_atf is used to generate a53 spl images. May >> >> Yeah, right. We also have a fit image for u-boot proper, that confused me. >> >>> be create a new one that packs fit image with u-boot and firmware. Or can you >>> check if binman in u-boot works for you? >> >> You mean, pack the u-boot proper with the firmware? Then we could stick the >> result in an signed fit image when needed. And I could read the offset of the >> firmware from the generated dtb - provided binman can deal with multiple >> configurations like we have. > > If that is possible I am okay with it. > I will definitely try to switch our SPI flash image generation to binman, but I didn't figure out how to use it for appending a binary to u-boot-nodtb.bin. To my current understanding of the tool, it is only able to write back the offsets of image elements to a single dtb. That breaks when you have multiple configurations to choose from. I also have to handle https://github.com/siemens/u-boot/blob/jan/iot2050/board/siemens/iot2050/u-boot.its, not just u-boot.dtb. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support 2020-08-13 12:12 ` Jan Kiszka @ 2020-08-17 11:31 ` Jan Kiszka 0 siblings, 0 replies; 27+ messages in thread From: Jan Kiszka @ 2020-08-17 11:31 UTC (permalink / raw) To: u-boot On 13.08.20 14:12, Jan Kiszka wrote: > On 11.08.20 20:01, Lokesh Vutla wrote: >> >> >> On 11/08/20 8:28 pm, Jan Kiszka wrote: >>> On 11.08.20 16:36, Lokesh Vutla wrote: >>>> Hi Jan, >>>> >>>> On 11/08/20 6:07 pm, Jan Kiszka wrote: >>>>> On 11.08.20 12:46, Lokesh Vutla wrote: >>>>>> >>>>>> >>>>>> On 11/08/20 4:12 pm, Jan Kiszka wrote: >>>>>>> On 11.08.20 12:33, Lokesh Vutla wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>>>>>>>> This brings watchdog support for the TI K3 SoCs, derived from >>>>>>>>> the Linux >>>>>>>>> kernel, augmented with firmware loading as needed on the AM65x. >>>>>>>>> >>>>>>>>> Tested on the AM65x EVM and the IOT2050 (also AM65x-based, >>>>>>>>> upstream >>>>>>>>> support will be posted soon). >>>>>>>>> >>>>>>>>> Changes in v2: >>>>>>>>> ???? - keep watchdog powered when handing over to Linux >>>>>>>>> ???? - drop unneeded explicit power-on >>>>>>>>> ???? - account for RTI firmware locking the power domain >>>>>>>> >>>>>>>> Patch 1 and 3 merged applied. >>>>>>>> >>>>>>> >>>>>>> Thanks. Still taking workable suggestions for loading the firmware. >>>>>> >>>>>> FIT image is the one that I can think off. Since SPL is loading >>>>>> the FIT image, >>>>>> SPL_HANDOFF can be used to pass on the loadaddr from SPL to U-Boot >>>>>> and U-Boot >>>>>> can start the remote cores using this info. >>>>> >>>>> OK, just the ensure I got the idea correctly: >>>>> >>>>> ???- extend struct spl_handoff or arch_spl_handoff with the fit image >>>>> ???? loadaddr that spl is processing >>>> >>>> Yes >>>> >>>>> >>>>> ???- stick the watchdog firmware into the u-boot proper fit image >>>>> ???? (generated by tools/k3_fit_atf.sh or shipped via the board >>>>> folder, as >>>>> ???? in our case) >>>> >>>> IMHO, not via board folder. k3_fit_atf is used to generate a53 spl >>>> images. May >>> >>> Yeah, right. We also have a fit image for u-boot proper, that >>> confused me. >>> >>>> be create a new one that packs fit image with u-boot and firmware. >>>> Or can you >>>> check if binman in u-boot works for you? >>> >>> You mean, pack the u-boot proper with the firmware? Then we could >>> stick the >>> result in an signed fit image when needed. And I could read the >>> offset of the >>> firmware from the generated dtb - provided binman can deal with multiple >>> configurations like we have. >> >> If that is possible I am okay with it. >> > > I will definitely try to switch our SPI flash image generation to > binman, but I didn't figure out how to use it for appending a binary to > u-boot-nodtb.bin. > > To my current understanding of the tool, it is only able to write back > the offsets of image elements to a single dtb. That breaks when you have > multiple configurations to choose from. I also have to handle > https://github.com/siemens/u-boot/blob/jan/iot2050/board/siemens/iot2050/u-boot.its, > not just u-boot.dtb. Just updated the branch to use binman for the flash image and also for replacing u-boot.its [1][2]. However, I still don't see how to use it for adding a firmware image into the fit parts AND finding it later on from U-Boot proper. Adding Simon, in case he has some idea. Jan [1] https://github.com/siemens/u-boot/commit/951e5294f14196a502e7fe238c23c49de49b8e29 [2] https://github.com/siemens/u-boot/blob/951e5294f14196a502e7fe238c23c49de49b8e29/arch/arm/dts/iot2050-boot-image.dtsi -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2020-08-17 11:31 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-23 11:15 [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support Jan Kiszka 2020-06-23 11:15 ` [PATCH v2 1/3] watchdog: Add support for K3 RTI watchdog Jan Kiszka 2020-06-23 11:47 ` Lokesh Vutla 2020-06-23 12:26 ` Jan Kiszka 2020-06-23 11:15 ` [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware Jan Kiszka 2020-06-23 11:50 ` Lokesh Vutla 2020-06-23 12:37 ` Jan Kiszka 2020-06-23 14:41 ` Jan Kiszka 2020-06-29 2:26 ` Lokesh Vutla 2020-06-29 4:50 ` Jan Kiszka 2020-06-29 4:54 ` Lokesh Vutla 2020-06-29 7:44 ` Jan Kiszka 2020-06-29 12:37 ` Tom Rini 2020-06-29 18:44 ` Jan Kiszka 2020-07-20 9:36 ` Jan Kiszka 2020-07-21 5:27 ` Lokesh Vutla 2020-07-21 6:26 ` Jan Kiszka 2020-06-23 11:15 ` [PATCH v2 3/3] arm: dts: k3: Add RTI watchdogs Jan Kiszka 2020-08-11 10:33 ` [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support Lokesh Vutla 2020-08-11 10:42 ` Jan Kiszka 2020-08-11 10:46 ` Lokesh Vutla 2020-08-11 12:37 ` Jan Kiszka 2020-08-11 14:36 ` Lokesh Vutla 2020-08-11 14:58 ` Jan Kiszka 2020-08-11 18:01 ` Lokesh Vutla 2020-08-13 12:12 ` Jan Kiszka 2020-08-17 11:31 ` Jan Kiszka
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.