[RFC] Pass reset reason to Linux via FDT

[RFC] Pass reset reason to Linux via FDT

[Sverdlin, Alexander]

Dear Device Tree Spec Team!

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?
- Do you think /chosen/reset-reason is the proper location for the SoC/platform
  agnostic reset cause information?
- Do you think having an opaque string there is OK, bearing in mind that there
  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
  information regarding reset cause, which is barely possible to unify?

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/u-boot@lists.denx.de/msg573811.html

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

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

[Quentin Schulz]

Hi Alexander,

Adding Ahmad for the Barebox side of things because they already use and 
set something in Device Tree as far as I remember.

On 5/12/26 9:27 AM, Sverdlin, Alexander wrote:
> Dear Device Tree Spec Team!
> 
> 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.

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.

What about an SoC with multiple watchdogs (Rockchip SoCs have many 
different sources for triggering the watchdog)?

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/u-boot@lists.denx.de/msg573811.html
> 

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

[Sverdlin, Alexander]

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

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?

> 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.

> 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/u-boot@lists.denx.de/msg573811.html
> > 

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com