[U-Boot] [PATCH 04/28] armv8/ls2085a: Fix generic timer clock source

[York Sun]

On 03/19/2015 11:46 AM, Mark Rutland wrote:
> On Thu, Mar 19, 2015 at 06:24:10PM +0000, York Sun wrote:
>> On 03/19/2015 11:17 AM, Mark Rutland wrote:
>>> On Thu, Mar 19, 2015 at 06:16:25PM +0000, York Sun wrote:
>>>> On 03/19/2015 11:08 AM, Mark Rutland wrote:
>>>>>> +
>>>>>> +int timer_init(void)
>>>>>> +{
>>>>>> +	u32 __iomem *cntcr = (u32 *)CONFIG_SYS_FSL_TIMER_ADDR;
>>>>>> +	u32 __iomem *cltbenr = (u32 *)CONFIG_SYS_FSL_PMU_CLTBENR;
>>>>>> +#ifdef COUNTER_FREQUENCY_REAL
>>>>>> +	unsigned long cntfrq = COUNTER_FREQUENCY_REAL;
>>>>>> +
>>>>>> +	/* Update with accurate clock frequency */
>>>>>> +	asm volatile("msr cntfrq_el0, %0" : : "r" (cntfrq) : "memory");
>>>>>> +#endif
>>>>>
>>>>> Is this executed on all CPUs, or do secondary CPUs have CNTFRQ
>>>>> programmed with the correct value elsewhere?
>>>>>
>>>>
>>>> Only the primary CPU runs here. The secondary CPU doesn't come here.
>>>
>>> Ok. Where does CNTFRQ get programmed for those CPUs?
>>>
>>> If it's necessary to write COUNTER_FREQUENCY_REAL to the primary CPU's
>>> CNTFRQ, that's also necessary on the secondaries before they enter the
>>> OS.
>>
>> Hmm, this may be a bug. Didn't hear any complain from Linux users. We found the
>> timer wasn't correct during bring-up. Let me check with internal team.
> 
> Cheers!
> 
> If the CPUs don't have matching CNTFRQ, things will work most of the
> time, but timekeeping will be broken in some cases (e.g. KVM guests,
> after a kexec). It's not possible for the OS to fix this up, so the boot
> protocol requires that it's programmed on all CPUs prior to entering the
> kernel.
> 
> Since commit 127161aaf0fcd376 ("arm64: add runtime system sanity
> checks"), Linux should complain at boot time if CNTFRQ is mismatched
> across CPUs. We've added other sanity checks since that commit.
> 

I checked again. We don't have this Linux commit for internal development.

For u-boot, the secondary CPUs only have cntfrq set in start.S which is a
compiling macro, not a real time value. We happen to have it same as the real
value so no one observed any issue. If the board reference clock changes (which
is possible), the clock needs to be fixed. I will update the patch after
verification.

York