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

[Stephen Boyd <sboyd@codeaurora.org>]

[-- Attachment #1: Type: text/plain, Size: 2465 bytes --]

On 09/11/14 17:14, Sonny Rao wrote:
> On Thu, Sep 11, 2014 at 4:56 PM, Stephen Boyd <sboyd@codeaurora.org
> <mailto:sboyd@codeaurora.org>> wrote:
>
>
>     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.

What's being forced? The way internal rom jumps to sram? Is there any
other way that secondary CPUs come out of reset on this SoC? From
looking at the code it seems like the only path is internal rom jumps to
sram (where rockchip_secondary_trampoline lives) which jumps to
rockchip_secondary_startup() which then does an invalidate and jump to
secondary_startup(). Linux controls everything besides the internal rom.
Is something different in your case?

>  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.
>

I'm thinking we would have a different boot-method for secure vs.
non-secure and then we would know to configure cntvoff or not based on
the boot method. Isn't that a reasonable way of knowing what should be
done? It seems like we can at least modify the DT for this SoC.

I still wonder if there is such a bootloader/hypervisor/rom that's
putting this SoC into non-secure mode and not configuring cntvoff.
Doug's comments seem to suggest that the whole world would be different
if this were true. Maybe Heiko knows?

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


[-- Attachment #2: Type: text/html, Size: 4405 bytes --]