Re: [PATCH v2] clocksource: arch_timer: Allow the device tree to specify the physical timer

On Thu, Sep 11, 2014 at 4:56 PM, Stephen Boyd [off-list ref] wrote:

On 09/11/14 10:43, Marc Zyngier wrote:

quoted

quoted

quoted

If I was suicidal, I'd suggest you could pass a parameter to the

command

quoted

quoted

quoted

line, interpreted by the timer code... But I since I'm not, let's
pretend I haven't said anything... ;-)

I did this in the past (again, see Sonny's thread), but didn't
consider myself knowledgeable to know if that was truly a good test:

       asm volatile("mrc p15, 0, %0, c1, c1, 0" : "=r" (val));
       pr_info("DOUG: val is %#010x", val);
       val |= (1 << 2);
       asm volatile("mcr p15, 0, %0, c1, c1, 0" : : "r" (val));
       val = 0xffffffff;
       asm volatile("mrc p15, 0, %0, c1, c1, 0" : "=r" (val));
       pr_info("DOUG: val is %#010x", val);

The idea being that if you can make modifications to the SCR register
(and see your changes take effect) then you must be in secure mode.
In my case the first printout was 0x0 and the second was 0x4.

The main issue is when you're *not* in secure mode. It is likely that
this will explode badly. This is why I suggested something that is set
by the bootloader (after all. it knows which mode it is booted in), and
that the timer driver can use when the CPU comes up.

Where does this platform jump to when a CPU comes up? Is it
rockchip_secondary_startup()? I wonder if that path could have this
little bit of assembly to poke the cntvoff in monitor mode and then jump
to secondary_startup()? Before we boot any secondary CPUs we could also
read the cntvoff for CPU0 in the platform specific layer (where we know
we're running in secure mode) and then use that value as the "reset"
value for the secondaries. Or does this platform boot up in secure mode
some times and non-secure mode other times?

Yes, In our case, with our firmware, we will go through some internal Rom
code and then jump to rockchip_secondary_startup, but I don't think it's
correct to force all users of this SoC to do it that way.  If there were a
reasonable way to determine for sure that we are in secure mode, then yes
we could do what you're suggesting, and I'd be happy to code that up.

I think the problem is that there isn't a great way to determine whether
we're in secure mode or not, and this is maybe by design?  I don't
particularly understand that design choice.  It would be nice to hear some
rationale from ARM folks.

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation