Re: [RFC] Pass reset reason to Linux via FDT

Hi,

On Wed, 13 May 2026 at 02:57, Sverdlin, Alexander
<[email protected]> wrote:
>
> Hi Quentin,
>
> On Tue, 2026-05-12 at 17:29 +0200, Quentin Schulz wrote:
> > > I would like to receive your opinion on the new /chosen/reset-reason property
> > > I would like to introduce in the spec and consequently in the U-Boot.
> > >
> > > I've posted an U-Boot patchset [1] with the proposed implementation which
> > > would work on TI K3 SoCs initially.
> > >
> > > - Do you think I need to send a formal patch to device tree spec?
> >
> > We (U-Boot) are not merging new Device Tree nodes or properties without
> > them being accepted in either the spec or in Linux kernel Device Tree
> > bindings, so it's not that we think you need to send a formal patch, is
> > that you must and it needs to be merged before we can use it.
> >
> > Yes, this can take months and be cumbersome but Device Tree is supposed
> > to represent the HW and be system-agnostic so we should make sure all
> > bootloaders or OSes understand and fill the Device Tree as intended.
> >
> > > - Do you think /chosen/reset-reason is the proper location for the SoC/platform
> > >     agnostic reset cause information?
> >
> > /chosen is likely the right place considering /chosen/bootsource which
> > is also added by the bootloader.
> >
> > > - Do you think having an opaque string there is OK, bearing in mind that there
> >
> > No.
> >
> > >     is no standard approach up to now to this topic, neither in Linux nor in
> > >     U-Boot, taking into account different SoCs and vendors provide very different
> >
> > In Barebox there is a way though. Strings are bad, and even more so if
> > they are free-form as vendors will either be very inventive and there
> > can also be typos.
> >
> > >     information regarding reset cause, which is barely possible to unify?
> > >
> >
> > I think you want to have a read of common/oftree.c in Barebox,
> > specifically the /chosen/reset-source-device, /chosen/reset-source,
> > /chosen/reset-source-instance properties as well as
> > common/reset_source.c where they also read /chosen/reset-source-priority.
>
> thanks for the reference! Barebox implementation looks nice, populates exactly
> /chosen/reset-source with a string and covers most of the reset sources with their
> - unknown
> - POR
> - RST
> - WDG
> - WKE
> - JTAG
> - THERM
> - EXT
> - BROWNOUT

I am not a fan of capital letters and abbreviations in device-tree
properties. I think we should have

cold
warm
watchdog
wakeup
jtag
thermal
external
brownout

>
> but TI K3 has also
> - ESM (Error Signalling Module)
> - DMSC (how U-Boot calls it now, I suppose Device Management something) or SMS (Security Management Subsystem, how TRM names it)
>
> and i.MX9 brings some
> - *LOCKUP (secure core's lockup)
> - [unhandled] exception (on a secure core)
> - FCCU (Fault Collection and Control Unit, similar to TI's ESM?)
> - ELE (EdgeLock Enclave)
> - BBM (Battery-Backed Module)
>
> If we do not want to intentionally lose this information, how can we accommodate
> for the above and future development in the device tree bindings?

You can add more options to the binding as needed.

>
> > There are multiple issues with the suggested implementation here. How do
> > we handle a device with multiple IPs possibly triggering the same kind
> > of reset? E.g. there can be a CPU watchdog but also a PMIC watchdog. The
> > difference is really important as on some system, you need to reset the
> > PMIC so the power-rails are reset and in the expected state.
>
> Obviously it will not be possible to satisfy the most sophisticated requirements
> with just one implementation. But as usual, we probably could cover 80% of
> use cases with 20% of effort.

I would expect 'watchdog' to mean SoC watchdog. If we need to specify
a PMIC watchdog we could perhaps add a 'reset-source' property?

But as Quentin mentions, we should get the bindings in first.

>
> > What about an SoC with multiple watchdogs (Rockchip SoCs have many
> > different sources for triggering the watchdog)?
>
> Probably Barebox implementation has an answer for this providing their
> /chosen/reset-source-instance and /chosen/reset-source-device (as a full
> DT node name), but implementing /chosen/reset-source neither strictly
> requires to implement reset-source-instance or reset-source-device now,
> nor does it block them from being implemented later.
>
> > Considering Barebox has had support for this for a very long time, I'm
> > sure they have some opinions on what to do and what not to do :)
> >
> > Cheers,
> > Quentin
> >
> > > The proposed change would look like following:
> > >
> > > diff --git a/dtschema/schemas/chosen.yaml b/dtschema/schemas/chosen.yaml
> > > index 63f3c12..d908426 100644
> > > --- a/dtschema/schemas/chosen.yaml
> > > +++ b/dtschema/schemas/chosen.yaml
> > > @@ -183,6 +183,20 @@ properties:
> > >          will assign devices in its usual manner, otherwise it will not try to
> > >          assign devices and instead use them as they are configured already.
> > >
> > > +  reset-reason:
> > > +    $ref: types.yaml#/definitions/string
> > > +    description:
> > > +      This property is set by the bootloader to indicate the reason for the
> > > +      most recent system reset, e.g. "POR" (power-on reset), "WDOG" (watchdog),
> > > +      "PIN" (external reset pin), "RST" (software warm reset), "THERMAL", etc.
> > > +      The set of possible values is platform-specific.
> > > +
> > > +      / {
> > > +              chosen {
> > > +                      reset-reason = "WDOG";
> > > +              };
> > > +      };
> > > +
> > >      smbios3-entrypoint:
> > >        $ref: types.yaml#/definitions/address
> > >        maxItems: 1
> > >
> > > [1] https://www.mail-archive.com/[email protected]/msg573811.html
> > >
>

Regards,
Simon