Re: [PATCH 3/3] ARM: Map the lowmem and kernel separately

From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Nishanth Menon <nm@ti.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Arnd Bergmann <arnd@arndb.de>,
	Linus Walleij <linus.walleij@linaro.org>,
	santosh.shilimkar@oracle.com, Tero Kristo <kristo@kernel.org>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 3/3] ARM: Map the lowmem and kernel separately
Date: Tue, 3 Aug 2021 11:49:33 +0100	[thread overview]
Message-ID: <20210803104932.GM22278@shell.armlinux.org.uk> (raw)
In-Reply-To: <f3eb9c84-19c6-cba2-ffcc-2dbcb48051ad@ti.com>

On Tue, Aug 03, 2021 at 01:27:18PM +0300, Grygorii Strashko wrote:
> 
> 
> On 31/07/2021 01:40, Linus Walleij wrote:
> > On Fri, Jul 30, 2021 at 10:23 PM Nishanth Menon <nm@ti.com> wrote:
> > > On 16:57-20210517, Linus Walleij wrote:
> > > > Using our knowledge of where the physical kernel sections start
> > > > and end we can split mapping of lowmem and kernel apart.
> > > > 
> > > [...]
> > > > 
> > > > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > > 
> > > 
> > > We noticed a regression in k2g platforms with this patch.
> > > commit 6e121df14ccd ("ARM: 9090/1: Map the lowmem and kernel
> > > separately")
> > > 
> > > Boot log: https://pastebin.ubuntu.com/p/Sf3r28D8MR/
> > > Bisect log: https://pastebin.ubuntu.com/p/6PTYpNVFDy/
> > 
> > Given how invasive the patch is I'm surprised that k2g is the
> > only thing so far complaining about it. Let's fix this!
> > 
> > I've had similar reports and in those cases it has been that the boot
> > loader did not turn off the caches before jumping to execute the
> > Linux kernel.
> > 
> > So first can you check that cache is off?
> > 
> > Next can you turn on DEBUG_LL and enable the debug messages
> > in arch/arm/mmu.c in map_lowmem() in some way that works for
> > you, for example I just add a patch like this:
> > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/patch/?id=d10c46631a6eaef1339e376b878de985143b27ff
> > (Beware of ugly debug habits!)
> > 
> > Next is this using the keystone 2 pv fixup thing  mdesc->pv_fixup
> > mdesc->pv_fixup in early_paging_init()?
> > 
> > I added a special print
> > there to see if that gets called. This code is really scary but I
> > suppose Santosh can explain what is supposed to happen here
> > and what I may have stepped on. (I see Santosh work at Oracle
> > now? Interesting.)
> 
> It should be called on all keystone 2 platforms by default (LAPE is default mode for K2).
> 
> Huh. Below as I remember it:
> - K2 starts using memory window (aliased memory) at 00 8000 0000 (No IO coherency is supported)
> - K2, early at boot, is switching to LPAE memory window 08 0000 0000 (IO coherency is supported)
>   so all, already mapped memory, has to be fixed - phys addresses.

If I remember correctly, the code that fixes that up assumes that
(a) the kernel is mapped using section mappings in the lowmem mapping
    at PAGE_OFFSET.._end-1
(b) that no other RAM is mapped (iow, it's called before the kernel
    starts building the real page mappings in paging_init()).

It looks to me like Linus missed the code in arch/arm/mm/pv-fixup-asm.S
and as the kernel is no longer mapped in the lowmem mapping, this
likely writes a load of entries in the page tables that are random...

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel