Hi Abhilash,
Abhilash Kesavan <kesavan.abhilash@xxxxxxxxx> writes:
[...]
>>> To be honest, since I don't have the exynos5420 arndale, chromebook...but smdk
>>> which has different bootloader, I couldn't test it...I'll try to make a test
>>> farm like you guys...
>>
>> Do you have some colleagues with any other 542x hardware? I had
>> assumed that linux-next was being better tested on the publicaly
>> available, and widely available boards like odroid-xu3 and
>> Chromebook2, but I've come to realize the hard way that that is not
>
> Are you seeing this on Chromebook2 (Peach-Pi 5800) too ?
No, it seems that my exynos5800-peach-pi is not having this problem,
which suggests it's a bootloader setup issue.
>> the case. You mention your board has a different bootloader. Do you
>> suspect there's a bootloader issue on these other platforms? If so,
>> could you elaborate on possible fixes? I'm more than willing to test
>> any proposed fixes, but I'm not familiar enough yet with these SoCs to
>> figure out the underlying issues alone.
>>
>> Until you have a working board farm, you could start having a closer
>> look at the boot logs we're already producing. Admittedly linux-next
>> broken in many ways besides this one for exynos currently, but it has
>> been having these imprecise aborts well before the other recent
>> issues.
>>
>> Also, It's very possible that this issue is not even MCPM related at
>> all, and MCPM is just uncovering a previously hidden bug. It would be
>> very helpful if people more familiar with this hardware and SoC would
>> investigate bug reports like these.
>
> The 3 boards I have access to (SMDK5420, Chromebook Peach-Pi and
> Chromebook Peach-Pit) work fine with MCPM enabled.
Thanks for helping look into this.
> I am not sure why
> it is failing only on the above mentioned boards as there is nothing
> specific to them in the MCPM back-end.
>
> I assume that when you default to platsmp (on disabling MCPM), the
> non-working boards boot all cores upto userspace without any issues ?
Nope. With MCPM disabled:
- 5420/arndale-octa: CPU0-3 come up (A15s)
- 5422/odroid-xu3: only CPU0 (A7)
- 5800/peach-pi: only CPU0 (A15)
Note that with MCPM enabled, the arndale-octa gets the same result.
Peach-pi on the other hand gets all 8 CPUs, and the odroid-xu3 only gets
6/8 CPUs (see other thread on that topic.)
> Based on the timeline (problems started about 2.5 months back), there
> have only been a couple of changes in the 5420 MCPM back-end. Could
> you revert the following commits and check if things improve.
>
> 20fe6f9 ARM: EXYNOS: Support cluster power off on exynos5420/5800
> fbb0499 ARM: 8083/1: exynos: activate the CCI on boot CPU/cluster
> using the MCPM loopback
>
> These might not revert cleanly, so instead of the above you could also
> comment the following 2 lines:
>
>
> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
> b/arch/arm/mach-exynos/mcpm-exynos.c
> index dc9a764..9a07188 100644
> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> @@ -152,7 +152,7 @@ static void exynos_power_down(void)
> exynos_cpu_power_down(cpunr);
>
> if (exynos_cluster_unused(cluster)) {
> - exynos_cluster_power_down(cluster);
> + //exynos_cluster_power_down(cluster);
> last_man = true;
> }
2> } else if (cpu_use_count[cpu][cluster] == 1) {
> @@ -356,8 +356,8 @@ static int __init exynos_mcpm_init(void)
> ret = mcpm_platform_register(&exynos_power_ops);
> if (!ret)
> ret = mcpm_sync_init(exynos_pm_power_up_setup);
> - if (!ret)
> - ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI */
> + //if (!ret)
> + //ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI */
> if (ret) {
> iounmap(ns_sram_base_addr);
> return ret;
>
>
>
> If you still get aborts then I suspect that the problem is with the
> bootloader configuration but am not sure.
Nice. With those lines commented out, the arndale-octa is not geting
imprecise aborts anymore, and this is the platform where those aborts
seem to prevent booting into a full userspace (as originally reported by
Tyler.)
More specifically, with only the loopback call to turn off CCI commented
out, the imprecise aborts go away.
The odroid-xu3 is still getting them, but these seem to happen whether
or not MCPM is enabled, so must a different issue related to the
bootloader setup.
> I am OK with disabling
> 5420_MCPM in the default configuration in such a case. This would
> however mean that S2R also stops working by default on 5420.
Disabling the option isn't my first choice either, I would rather see
this issue debugged and fixed by folks that are more familiar with MCPM
on Exynos.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
