[U-Boot] ARMv7 MMU shareability issue

Tom Rini trini at konsulko.com
Thu Dec 10 03:27:08 CET 2015


On Wed, Dec 09, 2015 at 03:09:13PM +0100, Marek Vasut wrote:
> On Wednesday, December 09, 2015 at 02:02:03 PM, Stefan Roese wrote:
> > 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.
> 
> This is a wrong approach, this patch just fixes another patch which was broken 
> from the getgo and the TTBR0 reg was not programmed correctly due to that. This
> patch must be applied, but what we need to decide is whether we need _another_
> patch which removes the S-bit from the pagetable or how to deal with that part.

No, we don't have to apply this patch.  The original patch here
(97840b5) was likely not run-time tested when submitted as it was using
the then-defunct CONFIG_ARMV7 symbol, and was likely a bugfix in an
internal tree that was pushed upstream (which is on the whole, good).
So in sum U-Boot has always been as broken in some specific regard
before that patch as it is after that patch.  So we have time to see
what we need to do about enabling this feature correctly and even
ensuring that we don't happen to say break things once Linux is up too.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151209/f1296a43/attachment.sig>


More information about the U-Boot mailing list