On 2015-02-17 11:21, Mark Rutland wrote: > On Tue, Feb 17, 2015 at 07:01:57AM +0000, Jan Kiszka wrote: >> On 2015-02-16 15:02, Jan Kiszka wrote: >>> On 2015-02-16 14:51, Mark Rutland wrote: >>>> On Mon, Feb 16, 2015 at 01:44:36PM +0000, Jan Kiszka wrote: >>>>> On 2015-02-16 14:37, Mark Rutland wrote: >>>>>> On Mon, Feb 16, 2015 at 12:54:49PM +0000, Jan Kiszka wrote: >>>>>>> We only set CNTFRQ in arch_timer_init for the boot CPU. But this has to >>>>>>> happen for all cores. >>>>>>> >>>>>>> Fixing this resolves problems of KVM with emulating the generic >>>>>>> timer/counter. >>>>>>> >>>>>>> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> >>>>>>> --- >>>>>>> arch/arm/cpu/armv7/tegra-common/psci.S | 13 +++++++++++++ >>>>>>> 1 file changed, 13 insertions(+) >>>>>>> >>>>>>> diff --git a/arch/arm/cpu/armv7/tegra-common/psci.S >>>>>>> b/arch/arm/cpu/armv7/tegra-common/psci.S >>>>>>> index b7501fb..119c246 100644 >>>>>>> --- a/arch/arm/cpu/armv7/tegra-common/psci.S >>>>>>> +++ b/arch/arm/cpu/armv7/tegra-common/psci.S >>>>>>> @@ -51,12 +51,25 @@ ENTRY(psci_arch_init) >>>>>>> >>>>>>> mrc p15, 0, r4, c0, c0, 5 @ MPIDR >>>>>>> and r4, r4, #7 @ number of CPUs in cluster >>>>>>> + >>>>>>> + adr r5, _sys_clock_freq >>>>>>> + cmp r4, #0 >>>>>>> + >>>>>>> + mrceq p15, 0, r7, c14, c0, 0 @ read CNTFRQ from CPU0 >>>>>>> + streq r7, [r5] >>>>>>> + >>>>>>> + ldrne r7, [r5] >>>>>>> + mcrne p15, 0, r7, c14, c0, 0 @ write CNTFRQ to CPU1..3 >>>>>> >>>>>> Is it not possible to have a hook that uses the same variable as >>>>>> arch_timer_init rather than doing a here copy? It seems a shame to >>>>>> duplicate the effort. >>>>> >>>>> The problem is related to the different address spaces. Here we run in >>>>> the secure monitor, arch_timer_init - to my understanding - in >>>>> non-secure mode. Didn't find a pattern so far how to transfer data (and >>>>> that shouldn't be more complex than the above code). >>>> >>>> Surely arch_timer_init must be run in a secure mode in order to be >>>> allowed to write to CNTFRQ? >>> >>> Ah, right. >>> >>>> >>>> If this is simply the easiest way of moving the data around then there's >>>> no real problem with it; it's just a shame that it only happens in the >>>> PSCI case. >>> >>> OK, I'll check again. Maybe it's easier than I thought. >> >> It isn't: the variable we would have to write - conditionally, i.e. not >> for the SPL build - is not yet where it will finally be. The monitor is >> copied later on, but the symbol points to the destination already. One >> can account for that, but the result won't get simpler and cleaner IMHO. > > Fair enough. As I mentioned earlier there's no real problem with the > above, it just seemed a shame that this was only done in the PSCI case. > > I take it for the quoted sequence above that the primary CPU runs > through this path before sending the secondaries through (and that > either there's a DSB somewhere between the write and waking up > secondaries or memory accesses are strongly ordered at this point).
Yes to both: The primary performs this init before starting the target OS, and the dsb is at latest in psci_cpu_on before kicking off a secondary CPU. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot