Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
[...] > 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). > > > > OK, I'll try it. > > I check the return value of is_hyp_mode_available() to catch whether EL1 or > EL2. > > The is_hyp_mode_available() returns 'false' during kernel booting. > - __boot_cpu_mode[0]: 0xe11 (BOOT_CPU_MODE_EL1) > - __boot_cpu_mode[1]: 0x0 Thanks for taking a look. It's unfortunate that CPUs aren't booted at EL2 (especially given that booting them at EL1N means the FW is doing more work to be less helpful to the OS), but at least they seem to be booted in consistent modes. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
[...] 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). OK, I'll try it. I check the return value of is_hyp_mode_available() to catch whether EL1 or EL2. The is_hyp_mode_available() returns 'false' during kernel booting. - __boot_cpu_mode[0]: 0xe11 (BOOT_CPU_MODE_EL1) - __boot_cpu_mode[1]: 0x0 Thanks for taking a look. It's unfortunate that CPUs aren't booted at EL2 (especially given that booting them at EL1N means the FW is doing more work to be less helpful to the OS), but at least they seem to be booted in consistent modes. Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi Mark, On 03/06/2015 09:18 PM, Chanwoo Choi wrote: > Hi, > > On 03/06/2015 08:40 PM, Mark Rutland wrote: [snip] >> 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). > > OK, I'll try it. I check the return value of is_hyp_mode_available() to catch whether EL1 or EL2. The is_hyp_mode_available() returns 'false' during kernel booting. - __boot_cpu_mode[0]: 0xe11 (BOOT_CPU_MODE_EL1) - __boot_cpu_mode[1]: 0x0 Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi Mark, On 03/06/2015 09:18 PM, Chanwoo Choi wrote: Hi, On 03/06/2015 08:40 PM, Mark Rutland wrote: [snip] 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). OK, I'll try it. I check the return value of is_hyp_mode_available() to catch whether EL1 or EL2. The is_hyp_mode_available() returns 'false' during kernel booting. - __boot_cpu_mode[0]: 0xe11 (BOOT_CPU_MODE_EL1) - __boot_cpu_mode[1]: 0x0 Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi, On 03/06/2015 08:40 PM, Mark Rutland wrote: >> 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. You're right. > >>> 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? I just used the lateset Linux 4.0-rc2 for PSCI (arch/arm64/kernel/psci.c) without any modification. Unfortunately, I don't know who is the h/w developer of Exynos5433 SoC. > >>> 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). OK, I'll try it. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
> 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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi, On 03/06/2015 08:40 PM, Mark Rutland wrote: 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. You're right. 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? I just used the lateset Linux 4.0-rc2 for PSCI (arch/arm64/kernel/psci.c) without any modification. Unfortunately, I don't know who is the h/w developer of Exynos5433 SoC. 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). OK, I'll try it. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
On 03/06/2015 03:54 AM, Mark Rutland wrote:
> Hi,
>
>> + psci {
>> + compatible = "arm,psci";
>> + method = "smc";
>> + cpu_off = <0x8402>;
>> + cpu_on = <0xC403>;
>> + };
>
> Back at v2 you mentioned that CPU_OFF wasn't working [1].
>
> Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
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.
>
>> 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.
>
> 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.
[test result of CPU0 on/off on Linux 4.0-rc2]
root@localhost:~# echo 0 > /sys/devices/system/cpu/cpu0/online
[ 420.965435] IRQ1 no longer affine to CPU0
[ 420.965439] IRQ2 no longer affine to CPU0
[ 4631.194227] CPU0: shutdown
root@localhost:~# echo 1 > /sys/devices/system/cpu/cpu0/online
[ 1164.601644] CPU0: failed to come online
-bash: echo: write error: Input/output error
As I experienced, Exynos SoC could not turn off the CPU0 (boot cpu).
I think that we may need the hidden information of Exynos5433 from Exynos5433
architector.
>
> 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?
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
> >> >> + psci {
> >> >> + compatible = "arm,psci";
> >> >> + method = "smc";
> >> >> + cpu_off = <0x8402>;
> >> >> + cpu_on = <0xC403>;
> >> >> + };
> >> >
> >> > Back at v2 you mentioned that CPU_OFF wasn't working [1].
> >> >
> >> > Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
> >>
> >> The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
> >> 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".
> 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?
Do other CPUs eventually log errors regarding the lockup? Or is the
machine completely dead from this point on?
> >> > 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?
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
On Fri, Mar 6, 2015 at 2:04 AM, Mark Rutland wrote:
> Hi,
>
> [...]
>
>> >> + psci {
>> >> + compatible = "arm,psci";
>> >> + method = "smc";
>> >> + cpu_off = <0x8402>;
>> >> + cpu_on = <0xC403>;
>> >> + };
>> >
>> > Back at v2 you mentioned that CPU_OFF wasn't working [1].
>> >
>> > Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
>>
>> The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
>> 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.
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.
>
>> > 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.
[snip]
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
[...]
> >> + psci {
> >> + compatible = "arm,psci";
> >> + method = "smc";
> >> + cpu_off = <0x8402>;
> >> + cpu_on = <0xC403>;
> >> + };
> >
> > Back at v2 you mentioned that CPU_OFF wasn't working [1].
> >
> > Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
>
> The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
> 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.
> > I take it CPUs boot at EL2?
Do the CPUs boot at EL1 or EL2?
[...]
> > The timer node should be moved under the root node. It doesn't live on
> > the bus; it's a component of the CPU.
>
> OK. I'll move it according to your comment.
Thanks.
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi Mark,
On Thu, Mar 5, 2015 at 9:24 PM, Mark Rutland wrote:
> On Thu, Mar 05, 2015 at 05:38:23AM +, Chanwoo Choi wrote:
>> This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
>> Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433
>> supports
>> PSCI (Power State Coordination Interface) v0.1.
>>
>> This patch includes following dt node to support Exynos5433 SoC:
>> 1. Octa core for big.LITTLE architecture
>> - Cortex-A53 LITTLE Quad-core
>> - Cortex-A57 big Quad-core
>> - Support PSCI v0.1
>
> [...]
>
>> + psci {
>> + compatible = "arm,psci";
>> + method = "smc";
>> + cpu_off = <0x8402>;
>> + cpu_on = <0xC403>;
>> + };
>
> Back at v2 you mentioned that CPU_OFF wasn't working [1].
>
> Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
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.
>
> I take it CPUs boot at EL2?
>
> [...]
>
>> + timer {
>> + compatible = "arm,armv8-timer";
>> + interrupts = <1 13 0xff04>,
>> +<1 14 0xff04>,
>> +<1 11 0xff04>,
>> +<1 10 0xff04>;
>> + };
>
> The timer node should be moved under the root node. It doesn't live on
> the bus; it's a component of the CPU.
OK. I'll move it according to your comment.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
On Thu, Mar 05, 2015 at 05:38:23AM +, Chanwoo Choi wrote:
> This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
> Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
> PSCI (Power State Coordination Interface) v0.1.
>
> This patch includes following dt node to support Exynos5433 SoC:
> 1. Octa core for big.LITTLE architecture
> - Cortex-A53 LITTLE Quad-core
> - Cortex-A57 big Quad-core
> - Support PSCI v0.1
[...]
> + psci {
> + compatible = "arm,psci";
> + method = "smc";
> + cpu_off = <0x8402>;
> + cpu_on = <0xC403>;
> + };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
I take it CPUs boot at EL2?
[...]
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <1 13 0xff04>,
> +<1 14 0xff04>,
> +<1 11 0xff04>,
> +<1 10 0xff04>;
> + };
The timer node should be moved under the root node. It doesn't live on
the bus; it's a component of the CPU.
Thanks,
Mark.
[1] https://lkml.org/lkml/2014/12/2/413
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
On 03/06/2015 03:54 AM, Mark Rutland wrote:
Hi,
+ psci {
+ compatible = arm,psci;
+ method = smc;
+ cpu_off = 0x8402;
+ cpu_on = 0xC403;
+ };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
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.
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.
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.
[test result of CPU0 on/off on Linux 4.0-rc2]
root@localhost:~# echo 0 /sys/devices/system/cpu/cpu0/online
[ 420.965435] IRQ1 no longer affine to CPU0
[ 420.965439] IRQ2 no longer affine to CPU0
[ 4631.194227] CPU0: shutdown
root@localhost:~# echo 1 /sys/devices/system/cpu/cpu0/online
[ 1164.601644] CPU0: failed to come online
-bash: echo: write error: Input/output error
As I experienced, Exynos SoC could not turn off the CPU0 (boot cpu).
I think that we may need the hidden information of Exynos5433 from Exynos5433
architector.
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?
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
On Fri, Mar 6, 2015 at 2:04 AM, Mark Rutland mark.rutl...@arm.com wrote:
Hi,
[...]
+ psci {
+ compatible = arm,psci;
+ method = smc;
+ cpu_off = 0x8402;
+ cpu_on = 0xC403;
+ };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
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.
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.
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.
[snip]
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
[...]
+ psci {
+ compatible = arm,psci;
+ method = smc;
+ cpu_off = 0x8402;
+ cpu_on = 0xC403;
+ };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
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.
I take it CPUs boot at EL2?
Do the CPUs boot at EL1 or EL2?
[...]
The timer node should be moved under the root node. It doesn't live on
the bus; it's a component of the CPU.
OK. I'll move it according to your comment.
Thanks.
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi Mark,
On Thu, Mar 5, 2015 at 9:24 PM, Mark Rutland mark.rutl...@arm.com wrote:
On Thu, Mar 05, 2015 at 05:38:23AM +, Chanwoo Choi wrote:
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433
supports
PSCI (Power State Coordination Interface) v0.1.
This patch includes following dt node to support Exynos5433 SoC:
1. Octa core for big.LITTLE architecture
- Cortex-A53 LITTLE Quad-core
- Cortex-A57 big Quad-core
- Support PSCI v0.1
[...]
+ psci {
+ compatible = arm,psci;
+ method = smc;
+ cpu_off = 0x8402;
+ cpu_on = 0xC403;
+ };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
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.
I take it CPUs boot at EL2?
[...]
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff04,
+1 14 0xff04,
+1 11 0xff04,
+1 10 0xff04;
+ };
The timer node should be moved under the root node. It doesn't live on
the bus; it's a component of the CPU.
OK. I'll move it according to your comment.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
+ psci {
+ compatible = arm,psci;
+ method = smc;
+ cpu_off = 0x8402;
+ cpu_on = 0xC403;
+ };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
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.
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?
Do other CPUs eventually log errors regarding the lockup? Or is the
machine completely dead from this point on?
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?
Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
On Thu, Mar 05, 2015 at 05:38:23AM +, Chanwoo Choi wrote:
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
PSCI (Power State Coordination Interface) v0.1.
This patch includes following dt node to support Exynos5433 SoC:
1. Octa core for big.LITTLE architecture
- Cortex-A53 LITTLE Quad-core
- Cortex-A57 big Quad-core
- Support PSCI v0.1
[...]
+ psci {
+ compatible = arm,psci;
+ method = smc;
+ cpu_off = 0x8402;
+ cpu_on = 0xC403;
+ };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
I take it CPUs boot at EL2?
[...]
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff04,
+1 14 0xff04,
+1 11 0xff04,
+1 10 0xff04;
+ };
The timer node should be moved under the root node. It doesn't live on
the bus; it's a component of the CPU.
Thanks,
Mark.
[1] https://lkml.org/lkml/2014/12/2/413
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
