I've been hardening up hardware watchdog support on our custom i.MX6q based boards and think I have found a bug in the U-Boot imx watchdog driver (imx_watchdog.c).
Currently in the function hw_watchdog_init(), the watchdog control register bits are explicitly initialised as follows: writew(WCR_WDZST | WCR_WDBG | WCR_WDE | WCR_WDT | WCR_SRS | SET_WCR_WT(timeout), &wdog->wcr); Bit WCR_WDA (bit 5; 0x20) is not mentioned and is therefore set to zero. The function of that bit is: "WDA: WDOG_B assertion. Controls the software assertion of the WDOG_B signal. 0 = Assert WDOG_B output. 1 = No effect on system (Default)." [Ref. i.MX 6Dual/6Quad Applications Processor Reference Manual, Rev. 3, 07/2015, p5791]. Furthermore: "70.5.6.2 WDOG_B generation The WDOG asserts WDOG_B in the following scenarios: - Software write to WDA bit of Watchdog Control Register (WDOG_WCR). WDOG_B signal remains asserted as long as the WDA bit is '0'. ..." [Ref. i.MX 6Dual/6Quad Applications Processor Reference Manual, Rev. 3, 07/2015, p5785] Sure enough, on my board I'm seeing WDOG1_B being permanently asserted as soon as that line is executed. I think that line should be: writew(WCR_WDZST | WCR_WDBG | WCR_WDE | WCR_WDT | WCR_SRS | *WCR_WDA |* SET_WCR_WT(timeout), &wdog->wcr); (And obviously WCR_WDA needs to be defined in "include/fsl_wdog.h".) Once I made that change, WDOG1_B is no longer asserted when that line is run and behaves as I expect - i.e. WDOG1_B is asserted when the watchdog actually fires. Do others agree - am I on the right track? If so, should I submit a patch? (Something I have never done before and should learn how to do...) Regards, Ross Parker. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
