[PATCH] arm64: Fix map_range() not splitting mapped blocks

Marc Zyngier maz at kernel.org
Tue Mar 26 10:21:52 CET 2024


On Tue, 19 Mar 2024 12:39:26 +0000,
Pierre-Clément Tosi <ptosi at google.com> wrote:
> 
> Hi Fabio,
> 
> On Tue, Mar 19, 2024 at 09:13:12AM -0300, Fabio Estevam wrote:
> > Hi Pierre,
> > 
> > On Tue, Mar 19, 2024 at 8:39 AM Pierre-Clément Tosi <ptosi at google.com> wrote:
> > 
> > > This means gd->arch.tlb_addr pointing to the live PTs during setup_pgtables().
> > >
> > > In arch/arm/cpu/armv8, setup_all_pgtables() runs with SCTLR_ELx.M unset.
> > >
> > > In arch/arm/cpu/armv8/fsl-layerscape, setup_pgtables() is called twice:
> > >
> > >  - early_mmu_setup() calls it with SCTLR_ELx.M unset;
> > >  - final_mmu_setup() overwrites gd->arch.tlb_addr before calling it iff
> > >    CFG_SYS_MEM_RESERVE_SECURE is defined i.e. if CONFIG_SYS_SOC="fsl-layerscape"
> > >    so that <asm/arch-fsl-layerscape/config.h> gets auto-included through
> > >    <include/config.h>.
> > >
> > > So can CONFIG_FSL_LAYERSCAPE be set while CONFIG_SYS_SOC != "fsl-layerscape"?
> > 
> > No, this cannot happen.
> 
> Thanks for confirming.
> 
> For clarity, it might then make sense to drop that #ifdef in final_mmu_setup().
> 
> > Only the following Layerscape SoCs select CONFIG_FSL_LAYERSCAPE
> > in arch/arm/cpu/armv8/fsl-layerscape/Kconfig:
> > LS1012A, LS1028A, LS1043A, LS1046A, LS1088A, LS2080A, LX2162A and LX2160A
> > 
> > I saw the original boot problem with the i.MX8QX.
> > 
> > The i.MX8QX is part of the i.MX family, not the Layerscape family.
> 
> Sure.
> 
> To be clear, the concern here was that split_block() doesn't perform what the
> CPU architecture requires when modifying page tables that the MMU is using and
> the question therefore was: can setup_pgtables() be called on such live PTs?
> 
> For most AArch64 U-Boot ports (including the i.MX family), the answer is trivial
> because they use the arch code i.e. setup_all_pgtables(). However, as
> fsl-layerscape re-implements mmu_setup(), it had to be looked at separately,
> hence my question, which you answered above.

Thanks for the details.

With that,

Reviewed-by: Marc Zyngier <maz at kernel.org>

	M.

-- 
Without deviation from the norm, progress is not possible.


More information about the U-Boot mailing list