[U-Boot] ARMv7 MMU shareability issue

[Stefan Roese]

Hi All!

On 09.12.2015 09:09, Albert ARIBAUD wrote:
> On Tue,  8 Dec 2015 14:43:42 +0100, Marek Vasut <marex at denx.de> wrote:
>> The arch/arm/lib/cache-cp15.c checks for CONFIG_ARMV7 and if this macro is
>> set, it configures TTBR0 register. This register must be configured for the
>> cache on ARMv7 to operate correctly.
>>
>> The problem is that noone actually sets the CONFIG_ARMV7 macro and thus the
>> TTBR0 is not configured at all. On SoCFPGA, this produces all sorts of minor
>> issues which are hard to replicate, for example certain USB sticks are not
>> detected or QSPI NOR sometimes fails to write pages completely.
>>
>> The solution is to replace CONFIG_ARMV7 test with CONFIG_CPU_V7 one. This is
>> correct because the code which added the test(s) for CONFIG_ARMV7 was added
>> shortly after CONFIG_ARMV7 was replaced by CONFIG_CPU_V7 and this code was
>> not adjusted correctly to reflect that change.
>
> Note:
>
> As discussed with Marek on IRC, this patch enables what is supposed to
> be the correct MMU settings for ARMv7, which causes a sharp Ethernet
> performance drop (40%) but also a strong general memory access
> performance hit (a copy of 4 MB is almost instantaneous without the
> patch and takes 2-3 seconds with it).

I've tested Marek's patch on my current Armada XP platform (also
ARMv7). And also noticed a performance drop by about 30-40%.
The dhrystone command can be used for this testing as well
(CONFIG_CMD_DHRYSTONE).

So this is definitely a NAK from me to this current patch. It
fixes the issue on SoCFPGA but affects other platforms in a
negative way (i.MX6, Armada XP / 38x and perhaps others too).
My feeling is, that SoCFPGA needs to get fixed in a way, without
affecting the other platforms.

Marek, have you checked if the dcache is enabled at all on
SoCFPGA with this patch applied? I remember that before my
patch to really enable the dcache on SoCFPGA, the performance
was so low. And I even could remove all caching functions
from the ethernet driver (invalidate and flush). And the
driver still worked without any issues.

> I would like to either fix the performance or come up with an
> explanation for it before I pick this patch.

Yes. Please don't apply it quickly.

Thanks,
Stefan