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