From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Wed, 9 Dec 2015 14:02:03 +0100 Subject: [U-Boot] ARMv7 MMU shareability issue In-Reply-To: <20151209090932.35f5c1a8@lilith> References: <1449582222-6506-1-git-send-email-marex@denx.de> <20151209090932.35f5c1a8@lilith> Message-ID: <5668264B.6050301@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi All! On 09.12.2015 09:09, Albert ARIBAUD wrote: > On Tue, 8 Dec 2015 14:43:42 +0100, Marek Vasut 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