Re: [PATCH] schemas: chosen: Add reset-reason property

Hi Alexander,

On Tue, 26 May 2026 at 12:19, Sverdlin, Alexander
<[email protected]> wrote:
>
> Hi Simon,
>
> On Tue, 2026-05-26 at 09:10 -0500, Simon Glass wrote:
> > > Bootloaders such as U-Boot and barebox can populate the /chosen node with
> > > a reset-reason string property indicating the cause of the most recent
> > > system reset.
> > >
> > > Define a standardized set of generic reset reason values that bootloaders
> > > map their platform-specific reset sources to:
> > >
> > >    unknown    - reset source could not be determined
> > >    cold       - power-on reset
> > >    warm       - warm restart without full power cycle
> > >    watchdog   - watchdog timer expiration
> > >    wakeup     - wake from suspend/sleep
> > >    jtag       - JTAG/debug initiated reset
> > >    thermal    - thermal shutdown/overtemperature
> > >    external   - external reset pin/signal
> > >    brownout   - supply voltage drop
> > >    software   - explicit software-initiated reset
> > >    safety     - hardware fault detection (e.g. error signaling module,
> > >                 fault collection and control unit)
> > >    security   - security subsystem (e.g. secure enclave violation)
> >
> > These all seem fine to me
> >
> > >    pmic       - PMIC-initiated reset
> >
> > pmic seems more like a means than a reason. Could you give an example
> > of when this might be used, rather than the other reasons?
>
> you are most probably correct in that PMIC probably generates one of the
> other resets (external or cold), but i.MX firmware is able to provide this
> information [1], so it would be pity to throw it away?

Yes I see. Outside of the context of i.MX what should it mean? We need
to be explicit since someone else's hardware may not match i.MX and
they will be confused as to how to map things. I'm nervous about it
because it seems like a catch-all, i.e. the PMIC decided to do a reset
due to brownout or the software writing one of its registers
requesting a reset. But perhaps the best we can do is to define more
precisely what it means with respect to the others.

Another question is what happens when there are multiple reset
sources? Perhaps for now we don't allow that and say in the
description something like: If multiple reset sources are detected the
bootloader should report the most specific known cause; if the cause
cannot be determined, use "unknown".

If the property is missing that is then a clear sign that the
bootloader doesn't support it.

BTW I believe you should have | after the description so that the yaml
is not wrapped and whitespace is preserved. I can't remember if it
matters or not.

Regards,
Simon

>
> [1] https://github.com/u-boot/u-boot/blob/987907ae4bcc5d6055bdf7d318a3edf53e14d5fa/arch/arm/mach-imx/imx9/scmi/soc.c#L591
>
> --
> Alexander Sverdlin
> Siemens AG
> www.siemens.com