[U-Boot] [PATCH] arm: ls1021a: Ensure LS1021 ARM Generic Timer CompareValue Set 64-bit

[Marc Zyngier <marc.zyngier@arm.com>]

Alison,

On 17/07/15 11:01, Huan Wang wrote:
> Hi, Mark,
> 
>>> On Wed, Jul 15, 2015 at 08:13:05AM +0100, Alison Wang wrote:
>>>> This patch addresses a problem mentioned recently on this mailing
>>> list:
>>>> [1].
>>>>
>>>> In that posting a LS1021 based system was locking up at about 5
>>>> minutes after boot, but the problem was mysteriously related to the
>>>> toolchain used for building u-boot.  Debugging the problem reveals
>> a
>>>> stuck interrupt 29 on the GIC.
>>>>
>>>> It appears Freescale's LS1021 support in u-boot erroneously sets
>> the
>>>> 64-bit ARM generic PL1 physical time CompareValue register to all-
>>> ones
>>>> with a 32-bit value.  This causes the timer compare to fire 344
>>>> seconds after u-boot configures it.  Depending on how fast u-boot
>>> gets
>>>> the kernel booted, this amounts to about 5-minutes of Linux uptime
>>>> before locking up.
>>>
>>> If as in [2] this is an attempt to not generate interrupts that Linux
>>> doesn't expect, it would be far better to simply disable the timer
>>> interrupt before leaving U-Boot, ensuring that unexpected interrupts
>>> are never generated regardless of the width or rate of the counter.
>>>
>>> There are bits in CNTP_CTL to do this.
>> [Alison Wang] Yes, your idea is far better.
> [Alison Wang] If the CompareValue register is not written, is there any unexpected
> Interrupt? How about removing the following code?
> 
> /* Set PL1 Physical Comp Value */
> val = TIMER_COMP_VAL;
> asm("mcrr p15, 2, %Q0, %R0, c14" : : "r" (val));

There is two aspects to it:

- if you're not using the timer at all, there is no point writing to the
comparator.

- but whether you're using it or not, it is good practice to turn it off
before jumping into the OS: this OS may run non-secure and will then be
unable to turn the secure timer off.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...