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

[Quentin Schulz <quentin.schulz@cherry.de>]

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
>