From: Lucas Stach <l.stach@pengutronix.de>
To: Sascha Hauer <s.hauer@pengutronix.de>,
Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Barebox List <barebox@lists.infradead.org>
Subject: Re: [RFC] ARM: mmu: Do not try to pick early TTB up
Date: Fri, 25 May 2018 11:09:48 +0200 [thread overview]
Message-ID: <1527239388.3472.4.camel@pengutronix.de> (raw)
In-Reply-To: <20180525090124.wchev5lakkiny2gr@pengutronix.de>
Am Freitag, den 25.05.2018, 11:01 +0200 schrieb Sascha Hauer:
> On Thu, May 24, 2018 at 08:14:40PM -0700, Andrey Smirnov wrote:
> > On Wed, May 23, 2018 at 1:43 AM, Sascha Hauer <s.hauer@pengutronix.
> > de> wrote:
> > > On Tue, May 22, 2018 at 10:10:12PM -0700, Andrey Smirnov wrote:
> > > > The call to create_flat_mapping() in mmu.c will change both
> > > > memory
> > > > type and shareability of all RAM in use by barebox while MMU is
> > > > on
> > > > when done in conjunction with CONFIG_MMU_EARLY.
> > >
> > > I notice that with MMU_EARLY enabled we call
> > > create_flat_mapping()
> > > twice, once in the early MMU code and once when setting up the
> > > MMU for
> > > real. In between we remap the the SDRAM cached which then is
> > > reverted
> > > during the second call to create_flat_mapping().
> > >
> > > This seems unnecessary. Does the following help you?
> >
> > Yeah, this, disabling MMU before or having a tlb_invalidate() after
> > all seem to help. Your patch works fine, but it has a slight
> > weirdness
> > in my case because early MMU code would mark OCRAM as cached and
> > regular MMU code wouldn't undo it without the call to
> > create_flat_mapping(), so I'd end up with slightly different memory
> > configuration depending on if EARLY_MMU is enabled or not. Other
> > than
> > that it should work fine.
> >
> > The main reason I chose to go "disable MMU" route is because that
> > follows what ARMv8 MMU code does, but I am perfectly happy with
> > either
> > solution.
>
> Disabling the MMU probably has a performance impact (I would have to
> remeasure, maybe this is not true at all), that's why I would prefer
> keeping it enabled.
It's probably worse with CPUs that have the L2 cache as an architected
cache, like the Cortex A8 and A15. On those we would need to flush the
pretty large L2 cache in order to disable the MMU.
Regards,
Lucas
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2018-05-25 9:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-23 5:10 Andrey Smirnov
2018-05-23 8:43 ` Sascha Hauer
2018-05-25 3:14 ` Andrey Smirnov
2018-05-25 9:01 ` Sascha Hauer
2018-05-25 9:09 ` Lucas Stach [this message]
2018-05-25 17:07 ` Andrey Smirnov
2018-05-25 17:09 ` Andrey Smirnov
2018-05-25 17:35 ` Sam Ravnborg
2018-05-28 12:05 ` Sascha Hauer
2018-05-28 18:08 ` Andrey Smirnov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1527239388.3472.4.camel@pengutronix.de \
--to=l.stach@pengutronix.de \
--cc=andrew.smirnov@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox