[U-Boot] [PATCH 0/4] ARM: imx6: DHCOM i.MX6 PDK: Fixing reset

[Claudius Heine]

Hi Robert,

On 28/11/2019 17.17, Robert Hancock wrote:
> On 2019-11-28 6:34 a.m., Harald Seiler wrote:
>> Hello Claudius,
>>
>> On Thu, 2019-11-28 at 13:06 +0100, Claudius Heine wrote:
>>> Hi,
>>>
>>> currently the reset on the DHCOM i.MX6 board is brocken in u-boot.
>>>
>>> This patchset fixes that by integrating the sysreset and watchdog dm driver.
>>
>> I think you should clarify that reset was broken by commit f2929d11a639
>> ("watchdog: imx: Use immediate reset bits for expire_now") which changed
>> reset to, by default, only assert the external reset [1].  DHCOM i.MX6
>> needs the internal reset though, which previously was asserted as as
>> well.  Maybe you can add a `Fixes:` line to one of your commits?
> 
> The behavior of the driver in the DM mode should match what the Linux
> IMX watchdog driver is doing for both the watchdog timeout and reset
> operations. The reset operation there explicitly uses either internal
> reset or external reset, not both. For the actual watchdog timeout, they
> both set the WDT bit or not depending on whether ext-reset is set, which
> it seems would result in either internal+external reset or just internal
> reset (it doesn't look like you can trigger only an external reset on
> timeout).
> 
>>
>> Additionally, I am still unsure whether the current default behavior is
>> correct.  I'd rather assert both external and internal reset, which is
>> what the i.MX watchdog does on timeout as well (as long as WDT bit is
>> set, which we do by default [2]).  There is also an inconsistency
>> between the non-DM implementation (external by default) and DM
>> implementation (internal by default).
> 
> The legacy non-DM implementation kept the settings for timeout the same
> as they were before. For the reset, it appears that it used to do
> internal+external reset whereas now it does external only, so it's
> possible that might cause an issue on some boards. However, they should
> really be switching to DM and setting the ext-reset attribute properly
> depending on which reset they actually want, as that's needed to get
> proper watchdog timeout/restart behavior in Linux as well. I doubt any
> board actually needs both internal and external resets since then Linux
> would be unable to reboot properly.

Thx, for the explanation! An issue I could think of is in the SPL, where
DM is not possible because of size limitations. If that SPL wants to
trigger a reset, will that not cause only an external reset and boards
that need a internal one will just hang?

If that is the case, then there probably should be a way to configure
that or let it trigger both like it did before.

regards,
Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch at denx.de

           PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                             Keyserver: hkp://pool.sks-keyservers.net