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

Eric Nelson
2015-02-05T17:22:33Z

Hi Stefano,

On 02/05/2015 10:19 AM, Stefano Babic wrote:
> Hi Bill,
>
> On 05/02/2015 17:28, Bill Pringlemeir wrote:
>> On 4 Feb 2015, eric.nelson at boundarydevices.com wrote:
>>
>>> The cause of a reset is generally useful, and shouldn't be
>>> blindly cleared in the process of displaying it as a part
>>> of the boot announcement.
>>>
>>> If a particular system wants to clear it out, this should
>>> be done later after there's an opportunity for code or
>>> boot commands to read the value.
>>>
>>> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
>>> ---
>>> arch/arm/imx-common/cpu.c | 1 -
>>> 1 file changed, 1 deletion(-)
>>>
>>> diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
>>> index 28ccd29..3e0a582 100644
>>> --- a/arch/arm/imx-common/cpu.c
>>> +++ b/arch/arm/imx-common/cpu.c
>>> @@ -30,7 +30,6 @@ char *get_reset_cause(void)
>>> struct src *src_regs = (struct src *)SRC_BASE_ADDR;
>>>
>>> cause = readl(&src_regs->srsr);
>>> - writel(cause, &src_regs->srsr);
>>>
>>> switch (cause) {
>>> case 0x00001:
>>
>> There is very similar code in 'arch/arm/cpu/armv7/vf610/generic.c'. The
>> write is for a hard power on case where these reason registers are full
>> of weird bogus values (at least on Vybrid; I suspect on iMx). In the
>> case of a non-POR, the register bits are good. However, if you don't
>> clear the status, on the next reset it may have multiple registers bits
>> even though you really want to know the last reason (bit).
>>
>> Another option would be to clear the value and store the 'cause'
>> somewhere for other U-Boot users. Unless you wanted to read this from
>> an OS? I think both files should behave the same, all else equal.
>>
>
> I have assumed (maybe wrong ?) that the reason for the patch is to let
> the OS reading these bits.
>

In some cases (Windows Embedded), yes.

In the Linux case, we'll likely pass the value to the kernel through
the kernel command-line, so it's available to userspace.

I'm not aware of any kernel functionality for this at the moment.

Regards,

Eric