> >>>> CPU0 (boot CPU) is only well working for CPU_OFF. > >>>> But when I try to turn on the CPU0 after CPU_OFF, I failed it. > >>> > >>> That's rather worrying. Can you look into what's going on here? I'd > >>> rather not have dts describing things which are known to be broken. > >> > >> The board dts don't include any node for CPU_ON/OFF. > > > > I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node > > quoted above, and all the CPUs had enable-method = "psci". > > I mean that there are not additional dt node except for 'cpu' and 'psci' node. The psci node and cpu enable-method are sufficient. No other nodes should be relevant. > > > >> When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen. > >> After lockup happen, I cannot use the console. > > > > That sounds like a pretty major bug. > > > > Are you able to investigate with a hardware debugger? > > I can't do because there are not any jtag connector. That is very unfortunate. Which PSCI implementation are you using? Surely whoever developed it has access to debug. Surely they should have tested this? > > Do other CPUs eventually log errors regarding the lockup? Or is the > > machine completely dead from this point on? > > I tested CPU0 on/off. When I turn on the CPU0, I fail it. But, kernel just show the error log without lockup. > I gave you wrong infromation about CPU0 off. Ok. However that's still a major bug. [...] > >>>>> I take it CPUs boot at EL2? > >>> > >>> Do the CPUs boot at EL1 or EL2? > >> > >> Unfortunately, I cannot check the secure firmware for Exynos5433 SoC. > >> I think that a few SoC provider probably would know it. > > > > I guess I asked the wrong question. > > > > Do CPUs enter the kernel at EL2 or at EL1? > > Could you give me a tip how to check the kernel at EL2 or EL1? Hmm... I thought we logged this but it looks like we don't. You could hack in a check of is_hyp_mode_available() and is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, and whether all CPUs enter at the same mode (mandatory per the boot protocol). Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
