From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Date: Mon, 20 Jul 2020 11:36:11 +0200 Subject: [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware In-Reply-To: <8949b799-8d57-180a-8ade-9c218e531f02@siemens.com> References: <3897255c-f9c7-972e-56e2-6a0036c927fc@ti.com> <9d73c60b-9630-f774-db88-a762bec26251@siemens.com> <20200629123710.GP8432@bill-the-cat> <8949b799-8d57-180a-8ade-9c218e531f02@siemens.com> Message-ID: <48a4d8ad-92d2-5278-43a8-2117ee3d6974@siemens.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>>>>>> >>>>>>> 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 >>>>>>> --- >>>>>>> ?? 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 >>>>>>> ?? #include >>>>>>> ?? #include >>>>>>> +#include >>>>>>> ?? /* 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