Reset cause API

Reset cause API

[Ben Warren]

Hello,

Is there an API call, either Linux or PowerPC-specific, for determining
the cause of the last reset?  I can certainly read the RSR myself, but
why bother if the information's available elsewhere.

thanks,
Ben

Re: Reset cause API

[Kumar Gala]

On Mar 5, 2007, at 3:22 PM, Ben Warren wrote:

> Hello,
>
> Is there an API call, either Linux or PowerPC-specific, for  
> determining
> the cause of the last reset?  I can certainly read the RSR myself, but
> why bother if the information's available elsewhere.

There isnt anything like this since we don't have any consistent way  
of maintaining information across a reset.

Something like kexec could possibly do something.

- k

RE : Reset cause API

[alayrac]

The PPC405 recognizes three types of reset:
=95 Aprocessor reset affects the processor only, including the execution
units and cache units. External devices (on-chip and off-chip) are not
affected. This type of reset is sometimes referred to as a core reset.
=95 Achip reset affects the processor and all other devices or =
peripherals
located on the same chip as the processor.
=95 Asystem reset affects the processor chip and all other devices or
peripherals external to the processor chip that are connected to the
same system-reset network. The scope of a system reset depends on the
system implementation.

The type of reset is recorded in the most-recent reset field of the
debug-status register (DBSR[MRR]). System software can examine this
field if it needs to determine the cause of a reset. The effect of a
reset on the processor is always the same regardless of the type.

For more details you can see ppc-ref-guide.pdf (in EDK doc directory).
Chris

CRESITT INDUSTRIE
12 Rue de Blois, BP6744
45067 ORLEANS Cedex 2
Tel : 02.38.49.45.59
Fax :02.38.49.45.55
Email : christophe.alayrac@cresitt.com=20
Web : http://www.cresitt.com


<----> -----Message d'origine-----
<----> De=A0: linuxppc-embedded-
<----> bounces+christophe.alayrac=3Dcresitt.com@ozlabs.org
[mailto:linuxppc-
<----> embedded-bounces+christophe.alayrac=3Dcresitt.com@ozlabs.org] De =
la
<----> part de Kumar Gala
<----> Envoy=E9=A0: jeudi 8 mars 2007 15:30
<----> =C0=A0: bwarren@qstreams.com
<----> Cc=A0: linuxppc-embedded@ozlabs.org
<----> Objet=A0: Re: Reset cause API
<---->=20
<---->=20
<----> On Mar 5, 2007, at 3:22 PM, Ben Warren wrote:
<---->=20
<----> > Hello,
<----> >
<----> > Is there an API call, either Linux or PowerPC-specific, for
<----> > determining
<----> > the cause of the last reset?  I can certainly read the RSR
myself,
<----> but
<----> > why bother if the information's available elsewhere.
<---->=20
<----> There isnt anything like this since we don't have any consistent
way
<----> of maintaining information across a reset.
<---->=20
<----> Something like kexec could possibly do something.
<---->=20
<----> - k
<----> _______________________________________________
<----> Linuxppc-embedded mailing list
<----> Linuxppc-embedded@ozlabs.org
<----> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: RE : Reset cause API

[Ben Warren]

Thanks Chris & Kumar,
--- alayrac <christophe.alayrac@cresitt.com> wrote:


> The type of reset is recorded in the most-recent
> reset field of the
> debug-status register (DBSR[MRR]). System software
> can examine this
> field if it needs to determine the cause of a reset.
> The effect of a
> reset on the processor is always the same regardless
> of the type.
> 
> For more details you can see ppc-ref-guide.pdf (in
> EDK doc directory).
> Chris

The Freescale SoCs also have a Reset Status Register
(RSR) than contains the same kind of information.  I
wa s curious whether a system call exists or whether I
need to write my own.

What I'm really interested in knowing is whether the
last boot was cold(hard) or warm(soft).  The type of
products I work on have devices that must only be
initialized on a cold boot, to avoid affecting the
data path.

regards,
Ben