Re: [RFC] ARM: mmu: Do not try to pick early TTB up

From: Andrey Smirnov <andrew.smirnov@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Barebox List <barebox@lists.infradead.org>
Subject: Re: [RFC] ARM: mmu: Do not try to pick early TTB up
Date: Mon, 28 May 2018 11:08:41 -0700	[thread overview]
Message-ID: <CAHQ1cqEpx0P-DCbLNdE=iyCf6GwNqW96nxb8a_Ac8O_ftfg2Aw@mail.gmail.com> (raw)
In-Reply-To: <20180528120532.2imhhmkfu74rb2zr@pengutronix.de>

On Mon, May 28, 2018 at 5:05 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Fri, May 25, 2018 at 10:09:52AM -0700, Andrey Smirnov wrote:
>> On Fri, May 25, 2018 at 2:01 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> > 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.
>> >
>>
>> OK, sure. Where do we go from here? Do you want to just take your
>> patch or should I update mine, with its War And Peace of a commit
>> message, and incorporate what you proposed?
>
> I applied my patch for now. We can still disable the MMU between PBL and
> barebox later should we have to.
>

Sounds good, thanks!

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox