From: Ivan Mikhaylov <fr0st61te@gmail.com>
To: Andrew Jeffery <andrew@codeconstruct.com.au>,
Marc Olberding <molberding@nvidia.com>
Cc: joel@jms.id.au, openbmc@lists.ozlabs.org, eajames@linux.ibm.com
Subject: Re: [PATCH u-boot v2 1/2] drivers: spi: Add support for disabling FMC_WDT2 for aspeed
Date: Tue, 13 Jan 2026 23:55:06 +0300 [thread overview]
Message-ID: <c0fb8ab537cc9b234bf0afd4289c0e72a7e5ca04.camel@gmail.com> (raw)
In-Reply-To: <324c2abf90b0c1712b2407b9a9b6f80ae590cb4c.camel@codeconstruct.com.au>
On Mon, 2026-01-12 at 11:42 +1030, Andrew Jeffery wrote:
> On Tue, 2026-01-06 at 17:52 +0300, Ivan Mikhaylov wrote:
> > On Tue, Jan 6, 2026 at 3:05 AM Marc Olberding
> > <molberding@nvidia.com> wrote:
> > >
> > > On Sat, Jan 03, 2026 at 12:24:07AM +0300, Иван Михайлов wrote:
> > > > On Wed, Dec 3, 2025 at 2:53 AM Marc Olberding
> > > > <molberding@nvidia.com> wrote:
> > > > >
> > > > > Adds support for disabling the ast2600 FMC_WDT2 through
> > > > > a device tree entry in the fmc node.
> > > > > Set `aspeed,watchdog-disable` in your device tree to have
> > > > > the driver disable it.
> > > >
> > > > Marc, FMC_WDT2 doesn't disable watchdog, it controls ABR mode.
> > > > Watchdog with or without ABR still in operational mode.
> > > > So, maybe aspeed,abr-disable?
> > > >
> > > > Below namings probably should be corrected.
> > > We aren't disabling ABR mode with this change, right? That's only
> > > done through hardware straps or OTP changes. All this is doing is
> > > clearing bit 0
> > > of FMC64, which per the datasheet disables the watchdog. The idea
> > > here is
> > > to just allow boot to progress normally, without the watchdog.
> > > For ping pong update,
> > > userspace can flash the alternative SPI and re-enable the
> > > watchdog timer on complete,
> > > and the BMC will boot from the new image upon reset. Let me know
> > > if I'm misunderstanding
> > > your comment.
> > >
> >
> > Marc, when you clrbits_le on FMC64/FMC_WDT2, then you disable ABR
> > mode, I
> > assume you can check it with evb board or ast2600-a3 to prove. On
> > my board
> > ast2600-a3 it works in that way I described with enabled OTP strap
> > for ABR.
>
> Can you elaborate on the sequences involved?
Andrew, same as in this patch but with mw in u-boot run script with
enabled OTP strap for ABR.
> The reset definitions for the FMC suggest it's affected by an ARM
> reset, which should in-turn reinitialise FMC_WDT2 and follow the boot
> flow to enable the ABR again. In my understanding disabling it in
> firmware shouldn't prevent ABR operations subsequent to future
> resets?
As I know, yes.
>
> Further, the aspeed,watchdog-disable property is to be taken in the
> context of the node with the FMC compatible string, referring to the
> FMC's watchdog and not the (separate) SoC watchdogs. However the FMC
> does have multiple watchdogs, one for address mode detection and the
> other for ABR. So maybe the name of the property could be improved in
> that regard. I think it's still reasonable to have watchdog in the
> name. My immediate reaction is that "aspeed,abr-disable" overstates
> its
> behaviour. How about "aspeed,abr-watchdog-disable"? Previous
> suggestions were "fmc-wdt2-disable", and the current
> "aspeed,watchdog-
> disable"
>
I like both of these: "aspeed,abr-watchdog-disable", "aspeed,fmc-wdt2-
disable".
> >
> > Also description of it in 14.2.2 Alternative Boot Recovery
> > Function.
>
> The second bullet in that section says:
>
> When the firmware booting successfully, it should disable FMC_WDT2
> to stop booting switch
>
> This is what Marc is trying to achieve by providing the property.
> Other
> platforms may want to make the choice elsewhere.
>
> Andrew
I'm not saying that is Marc is doing something wrong about it, I just
want to say that need to distinguish WDT2 and FMC_WDT2 because it
puzzles when you reading the code in which you see something like:
/* FMC_WDT2 ... */
#define WDT2_ENABLE ...
I'd be use exactly what it should be:
/* FMC_WDT2 ... */
#define FMC_WDT2_ENABLE ...
and everything else which relates to FMC_WDT2.
Thanks.
next prev parent reply other threads:[~2026-01-13 20:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-02 23:52 [PATCH u-boot v2 0/2] aspeed: Add support for MSX4 Marc Olberding
2025-12-02 23:52 ` [PATCH u-boot v2 1/2] drivers: spi: Add support for disabling FMC_WDT2 for aspeed Marc Olberding
2025-12-16 23:23 ` Andrew Jeffery
2025-12-17 1:15 ` Marc Olberding
2025-12-17 1:18 ` Andrew Jeffery
2025-12-17 1:21 ` Andrew Jeffery
2025-12-17 1:24 ` Marc Olberding
2026-01-02 21:24 ` Иван Михайлов
2026-01-06 0:05 ` Marc Olberding
2026-01-06 14:52 ` Ivan Mikhaylov
2026-01-06 17:21 ` Marc Olberding
2026-01-12 1:12 ` Andrew Jeffery
2026-01-13 20:55 ` Ivan Mikhaylov [this message]
2026-02-10 1:19 ` Andrew Jeffery
2025-12-02 23:52 ` [PATCH u-boot v2 2/2] arch: arm: dts: Add dts for the nvidia msx4 board Marc Olberding
2025-12-17 0:05 ` Andrew Jeffery
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c0fb8ab537cc9b234bf0afd4289c0e72a7e5ca04.camel@gmail.com \
--to=fr0st61te@gmail.com \
--cc=andrew@codeconstruct.com.au \
--cc=eajames@linux.ibm.com \
--cc=joel@jms.id.au \
--cc=molberding@nvidia.com \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox