[U-Boot] [PATCH] imx: don't clobber reset cause

[Bill Pringlemeir]

On 10 Feb 2015, eric.nelson at boundarydevices.com wrote:

> I posted a couple of additional options and received no comment
> from you.

> Neither of them works as-is because of the ordering of events
> (print_cpuinfo() is called before restoring the environment),
> so your suggestion would require an additional call at startup
> which currently doesn't exist across i.MX boards.

> The primary argument against the original patch was that
> bits **could** accumulate. In practice, I believe this to
> be a bit of a red herring, since two bits cover essentially
> all of the normal conditions:

> 	bit 0 	- power on
> 	bit 4	- watchdog

Yes, the normal case is easy.  Odd things can happen during software
development.  We both agree you could miss something; maybe only whether
that is important is not clear.  People using the CSU to protect errant
memory writes to disabled peripherals might be useful.  From the imx6
RM,

    Software has to take care to clear this register by writing one
    after every reset that occurs so that the register will contain the
    information of recently occurred reset.

> The watchdog flag is set with reboot under Linux and reset
> in U-Boot, so we could re-work the switch statement to do
> the right thing. In fact, it appears broken now because it
> has 0x11 displaying "POR", when I believe that should be
> "WDOG".

I am pretty sure that the register is full of garbage on a 'POR', so the
'POR' bit overrides everything; at least on the Vybrid.  This is why it
is important to clear the bits.  The imx6DL-RM seems to say the same,

    When the system comes out of reset, this register will have bits set
    corresponding to all the reset sources that occurred during system
    reset.

> Other bits could conceivably accumulate, but I don't see
> the value of worrying about cases like "JTAG_RESET".

> The reason we're pursuing this at all is because we'd like
> to know the difference between a restart caused by power
> interruption and a system lockup, and we'd like to do
> this under Linux or Windows Embedded.

Please don't mis-understand.  I see value in what you are trying to
accomplish.  I just want to make sure the information that gets reported
is robust and correct.  It would probably be nice if the Vybrid followed
the same pattern; but maybe they are different?  From reading the RMs
they seem the same.

Regards,
Bill Pringlemeir.