| Message ID | 1506330344-31556-1-git-send-email-vladimir.murzin@arm.com |
|---|---|
| Headers | show |
| Series | ARM: NOMMU: MPU updates | expand |
Hi Vlad, On 09/25/2017 11:05 AM, Vladimir Murzin wrote: > Currently, there is assumption in early MPU setup code that kernel > image is located in RAM, which is obviously not true for XIP. To run > code from ROM we need to make sure that it is covered by MPU. However, > due to we allocate regions (semi-)dynamically we can run into issue of > trimming region we are running from in case ROM spawns several MPU > regions. To help deal with that we enforce minimum alignments for start > end end of XIP address space as 1MB and 128Kb correspondingly. > > Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Thanks for the XIP fix. Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> regards Alex > --- > arch/arm/Kconfig-nommu | 2 +- > arch/arm/include/asm/mpu.h | 3 ++- > arch/arm/kernel/head-nommu.S | 20 ++++++++++++++++ > arch/arm/kernel/vmlinux-xip.lds.S | 23 ++++++++++++++++++ > arch/arm/mm/pmsa-v7.c | 49 +++++++++++++++++++++++++++++++++++---- > 5 files changed, 90 insertions(+), 7 deletions(-) > > diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu > index 930e000..0fad7d9 100644 > --- a/arch/arm/Kconfig-nommu > +++ b/arch/arm/Kconfig-nommu > @@ -52,7 +52,7 @@ config REMAP_VECTORS_TO_RAM > > config ARM_MPU > bool 'Use the ARM v7 PMSA Compliant MPU' > - depends on !XIP_KERNEL && (CPU_V7 || CPU_V7M) > + depends on CPU_V7 || CPU_V7M > default y if CPU_V7 > help > Some ARM systems without an MMU have instead a Memory Protection > diff --git a/arch/arm/include/asm/mpu.h b/arch/arm/include/asm/mpu.h > index 5db37a6..56ec026 100644 > --- a/arch/arm/include/asm/mpu.h > +++ b/arch/arm/include/asm/mpu.h > @@ -41,6 +41,7 @@ > #endif > > /* Access permission bits of ACR (only define those that we use)*/ > +#define MPU_AP_PL1RO_PL0NA (0x5 << 8) > #define MPU_AP_PL1RW_PL0RW (0x3 << 8) > #define MPU_AP_PL1RW_PL0R0 (0x2 << 8) > #define MPU_AP_PL1RW_PL0NA (0x1 << 8) > @@ -49,7 +50,7 @@ > #define MPU_PROBE_REGION 0 > #define MPU_BG_REGION 1 > #define MPU_RAM_REGION 2 > -#define MPU_VECTORS_REGION 3 > +#define MPU_ROM_REGION 3 > > /* Maximum number of regions Linux is interested in */ > #define MPU_MAX_REGIONS 16 > diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S > index 8a0718f..2ce4455 100644 > --- a/arch/arm/kernel/head-nommu.S > +++ b/arch/arm/kernel/head-nommu.S > @@ -279,6 +279,26 @@ M_CLASS(ldr r0, [r12, #MPU_TYPE]) > setup_region r0, r5, r6, MPU_INSTR_SIDE r12 @ 0x0, BG region, enabled > 2: isb > > +#ifdef CONFIG_XIP_KERNEL > + set_region_nr r0, #MPU_ROM_REGION, r12 > + isb > + > + ldr r5,=(MPU_AP_PL1RO_PL0NA | MPU_RGN_NORMAL) > + > + ldr r0, =CONFIG_XIP_PHYS_ADDR @ ROM start > + ldr r6, =(_exiprom) @ ROM end > + sub r6, r6, r0 @ Minimum size of region to map > + clz r6, r6 @ Region size must be 2^N... > + rsb r6, r6, #31 @ ...so round up region size > + lsl r6, r6, #MPU_RSR_SZ @ Put size in right field > + orr r6, r6, #(1 << MPU_RSR_EN) @ Set region enabled bit > + > + setup_region r0, r5, r6, MPU_DATA_SIDE, r12 @ XIP_PHYS_ADDR, shared, enabled > + beq 3f @ Memory-map not unified > + setup_region r0, r5, r6, MPU_INSTR_SIDE, r12 @ XIP_PHYS_ADDR, shared, enabled > +3: isb > +#endif > + > /* Enable the MPU */ > AR_CLASS(mrc p15, 0, r0, c1, c0, 0) @ Read SCTLR > AR_CLASS(bic r0, r0, #CR_BR) @ Disable the 'default mem-map' > diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S > index 8265b11..c6f7056 100644 > --- a/arch/arm/kernel/vmlinux-xip.lds.S > +++ b/arch/arm/kernel/vmlinux-xip.lds.S > @@ -6,6 +6,8 @@ > /* No __ro_after_init data in the .rodata section - which will always be ro */ > #define RO_AFTER_INIT_DATA > > +#include <linux/sizes.h> > + > #include <asm-generic/vmlinux.lds.h> > #include <asm/cache.h> > #include <asm/thread_info.h> > @@ -205,6 +207,9 @@ SECTIONS > PERCPU_SECTION(L1_CACHE_BYTES) > #endif > > +#ifdef CONFIG_ARM_MPU > + . = ALIGN(SZ_128K); > +#endif > _exiprom = .; /* End of XIP ROM area */ > __data_loc = ALIGN(4); /* location in binary */ > . = PAGE_OFFSET + TEXT_OFFSET; > @@ -322,3 +327,21 @@ ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined") > */ > ASSERT(__hyp_idmap_text_end - (__hyp_idmap_text_start & PAGE_MASK) <= PAGE_SIZE, > "HYP init code too big or misaligned") > + > +#ifdef CONFIG_ARM_MPU > +/* > + * Due to PMSAv7 restriction on base address and size we have to > + * enforce minimal alignment restrictions. It was seen that weaker > + * alignment restriction on _xiprom will likely force XIP address > + * space spawns multiple MPU regions thus it is likely we run in > + * situation when we are reprogramming MPU region we run on with > + * something which doesn't cover reprogramming code itself, so as soon > + * as we update MPU settings we'd immediately try to execute straight > + * from background region which is XN. > + * It seem that alignment in 1M should suit most users. > + * _exiprom is aligned as 1/8 of 1M so can be covered by subregion > + * disable > + */ > +ASSERT(!(_xiprom & (SZ_1M - 1)), "XIP start address may cause MPU programming issues") > +ASSERT(!(_exiprom & (SZ_128K - 1)), "XIP end address may cause MPU programming issues") > +#endif > diff --git a/arch/arm/mm/pmsa-v7.c b/arch/arm/mm/pmsa-v7.c > index c1f1fc7..27434d7 100644 > --- a/arch/arm/mm/pmsa-v7.c > +++ b/arch/arm/mm/pmsa-v7.c > @@ -7,9 +7,11 @@ > #include <linux/bitops.h> > #include <linux/memblock.h> > > +#include <asm/cacheflush.h> > #include <asm/cp15.h> > #include <asm/cputype.h> > #include <asm/mpu.h> > +#include <asm/sections.h> > > #include "mm.h" > > @@ -20,6 +22,9 @@ struct region { > }; > > static struct region __initdata mem[MPU_MAX_REGIONS]; > +#ifdef CONFIG_XIP_KERNEL > +static struct region __initdata xip[MPU_MAX_REGIONS]; > +#endif > > static unsigned int __initdata mpu_min_region_order; > static unsigned int __initdata mpu_max_regions; > @@ -229,7 +234,6 @@ static int __init allocate_region(phys_addr_t base, phys_addr_t size, > /* MPU initialisation functions */ > void __init adjust_lowmem_bounds_mpu(void) > { > - phys_addr_t phys_offset = PHYS_OFFSET; > phys_addr_t specified_mem_size, total_mem_size = 0; > struct memblock_region *reg; > bool first = true; > @@ -256,8 +260,19 @@ void __init adjust_lowmem_bounds_mpu(void) > /* ... and one for vectors */ > mem_max_regions--; > #endif > + > +#ifdef CONFIG_XIP_KERNEL > + /* plus some regions to cover XIP ROM */ > + num = allocate_region(CONFIG_XIP_PHYS_ADDR, __pa(_exiprom) - CONFIG_XIP_PHYS_ADDR, > + mem_max_regions, xip); > + > + mem_max_regions -= num; > +#endif > + > for_each_memblock(memory, reg) { > if (first) { > + phys_addr_t phys_offset = PHYS_OFFSET; > + > /* > * Initially only use memory continuous from > * PHYS_OFFSET */ > @@ -355,7 +370,7 @@ static int __init __mpu_min_region_order(void) > > static int __init mpu_setup_region(unsigned int number, phys_addr_t start, > unsigned int size_order, unsigned int properties, > - unsigned int subregions) > + unsigned int subregions, bool need_flush) > { > u32 size_data; > > @@ -374,6 +389,9 @@ static int __init mpu_setup_region(unsigned int number, phys_addr_t start, > size_data = ((size_order - 1) << MPU_RSR_SZ) | 1 << MPU_RSR_EN; > size_data |= subregions << MPU_RSR_SD; > > + if (need_flush) > + flush_cache_all(); > + > dsb(); /* Ensure all previous data accesses occur with old mappings */ > rgnr_write(number); > isb(); > @@ -416,7 +434,28 @@ void __init mpu_setup(void) > /* Background */ > err |= mpu_setup_region(region++, 0, 32, > MPU_ACR_XN | MPU_RGN_STRONGLY_ORDERED | MPU_AP_PL1RW_PL0NA, > - 0); > + 0, false); > + > +#ifdef CONFIG_XIP_KERNEL > + /* ROM */ > + for (i = 0; i < ARRAY_SIZE(xip); i++) { > + /* > + * In case we overwrite RAM region we set earlier in > + * head-nommu.S (which is cachable) all subsequent > + * data access till we setup RAM bellow would be done > + * with BG region (which is uncachable), thus we need > + * to clean and invalidate cache. > + */ > + bool need_flush = region == MPU_RAM_REGION; > + > + if (!xip[i].size) > + continue; > + > + err |= mpu_setup_region(region++, xip[i].base, ilog2(xip[i].size), > + MPU_AP_PL1RO_PL0NA | MPU_RGN_NORMAL, > + xip[i].subreg, need_flush); > + } > +#endif > > /* RAM */ > for (i = 0; i < ARRAY_SIZE(mem); i++) { > @@ -425,14 +464,14 @@ void __init mpu_setup(void) > > err |= mpu_setup_region(region++, mem[i].base, ilog2(mem[i].size), > MPU_AP_PL1RW_PL0RW | MPU_RGN_NORMAL, > - mem[i].subreg); > + mem[i].subreg, false); > } > > /* Vectors */ > #ifndef CONFIG_CPU_V7M > err |= mpu_setup_region(region++, vectors_base, ilog2(2 * PAGE_SIZE), > MPU_AP_PL1RW_PL0NA | MPU_RGN_NORMAL, > - 0); > + 0, false); > #endif > if (err) { > panic("MPU region initialization failure! %d", err); >
Hi Alex, On 25/09/17 13:54, Alexandre Torgue wrote: > Hi Vlad, > > On 09/25/2017 11:05 AM, Vladimir Murzin wrote: >> Currently, there is assumption in early MPU setup code that kernel >> image is located in RAM, which is obviously not true for XIP. To run >> code from ROM we need to make sure that it is covered by MPU. However, >> due to we allocate regions (semi-)dynamically we can run into issue of >> trimming region we are running from in case ROM spawns several MPU >> regions. To help deal with that we enforce minimum alignments for start >> end end of XIP address space as 1MB and 128Kb correspondingly. >> >> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> > > > Thanks for the XIP fix. > > Tested-by: Alexandre TORGUE <alexandre.torgue@st.com> Much appreciated! Vladimir > > regards > Alex > > >> --- >> arch/arm/Kconfig-nommu | 2 +- >> arch/arm/include/asm/mpu.h | 3 ++- >> arch/arm/kernel/head-nommu.S | 20 ++++++++++++++++ >> arch/arm/kernel/vmlinux-xip.lds.S | 23 ++++++++++++++++++ >> arch/arm/mm/pmsa-v7.c | 49 +++++++++++++++++++++++++++++++++++---- >> 5 files changed, 90 insertions(+), 7 deletions(-) >> >> diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu >> index 930e000..0fad7d9 100644 >> --- a/arch/arm/Kconfig-nommu >> +++ b/arch/arm/Kconfig-nommu >> @@ -52,7 +52,7 @@ config REMAP_VECTORS_TO_RAM >> config ARM_MPU >> bool 'Use the ARM v7 PMSA Compliant MPU' >> - depends on !XIP_KERNEL && (CPU_V7 || CPU_V7M) >> + depends on CPU_V7 || CPU_V7M >> default y if CPU_V7 >> help >> Some ARM systems without an MMU have instead a Memory Protection >> diff --git a/arch/arm/include/asm/mpu.h b/arch/arm/include/asm/mpu.h >> index 5db37a6..56ec026 100644 >> --- a/arch/arm/include/asm/mpu.h >> +++ b/arch/arm/include/asm/mpu.h >> @@ -41,6 +41,7 @@ >> #endif >> /* Access permission bits of ACR (only define those that we use)*/ >> +#define MPU_AP_PL1RO_PL0NA (0x5 << 8) >> #define MPU_AP_PL1RW_PL0RW (0x3 << 8) >> #define MPU_AP_PL1RW_PL0R0 (0x2 << 8) >> #define MPU_AP_PL1RW_PL0NA (0x1 << 8) >> @@ -49,7 +50,7 @@ >> #define MPU_PROBE_REGION 0 >> #define MPU_BG_REGION 1 >> #define MPU_RAM_REGION 2 >> -#define MPU_VECTORS_REGION 3 >> +#define MPU_ROM_REGION 3 >> /* Maximum number of regions Linux is interested in */ >> #define MPU_MAX_REGIONS 16 >> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S >> index 8a0718f..2ce4455 100644 >> --- a/arch/arm/kernel/head-nommu.S >> +++ b/arch/arm/kernel/head-nommu.S >> @@ -279,6 +279,26 @@ M_CLASS(ldr r0, [r12, #MPU_TYPE]) >> setup_region r0, r5, r6, MPU_INSTR_SIDE r12 @ 0x0, BG region, enabled >> 2: isb >> +#ifdef CONFIG_XIP_KERNEL >> + set_region_nr r0, #MPU_ROM_REGION, r12 >> + isb >> + >> + ldr r5,=(MPU_AP_PL1RO_PL0NA | MPU_RGN_NORMAL) >> + >> + ldr r0, =CONFIG_XIP_PHYS_ADDR @ ROM start >> + ldr r6, =(_exiprom) @ ROM end >> + sub r6, r6, r0 @ Minimum size of region to map >> + clz r6, r6 @ Region size must be 2^N... >> + rsb r6, r6, #31 @ ...so round up region size >> + lsl r6, r6, #MPU_RSR_SZ @ Put size in right field >> + orr r6, r6, #(1 << MPU_RSR_EN) @ Set region enabled bit >> + >> + setup_region r0, r5, r6, MPU_DATA_SIDE, r12 @ XIP_PHYS_ADDR, shared, enabled >> + beq 3f @ Memory-map not unified >> + setup_region r0, r5, r6, MPU_INSTR_SIDE, r12 @ XIP_PHYS_ADDR, shared, enabled >> +3: isb >> +#endif >> + >> /* Enable the MPU */ >> AR_CLASS(mrc p15, 0, r0, c1, c0, 0) @ Read SCTLR >> AR_CLASS(bic r0, r0, #CR_BR) @ Disable the 'default mem-map' >> diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S >> index 8265b11..c6f7056 100644 >> --- a/arch/arm/kernel/vmlinux-xip.lds.S >> +++ b/arch/arm/kernel/vmlinux-xip.lds.S >> @@ -6,6 +6,8 @@ >> /* No __ro_after_init data in the .rodata section - which will always be ro */ >> #define RO_AFTER_INIT_DATA >> +#include <linux/sizes.h> >> + >> #include <asm-generic/vmlinux.lds.h> >> #include <asm/cache.h> >> #include <asm/thread_info.h> >> @@ -205,6 +207,9 @@ SECTIONS >> PERCPU_SECTION(L1_CACHE_BYTES) >> #endif >> +#ifdef CONFIG_ARM_MPU >> + . = ALIGN(SZ_128K); >> +#endif >> _exiprom = .; /* End of XIP ROM area */ >> __data_loc = ALIGN(4); /* location in binary */ >> . = PAGE_OFFSET + TEXT_OFFSET; >> @@ -322,3 +327,21 @@ ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined") >> */ >> ASSERT(__hyp_idmap_text_end - (__hyp_idmap_text_start & PAGE_MASK) <= PAGE_SIZE, >> "HYP init code too big or misaligned") >> + >> +#ifdef CONFIG_ARM_MPU >> +/* >> + * Due to PMSAv7 restriction on base address and size we have to >> + * enforce minimal alignment restrictions. It was seen that weaker >> + * alignment restriction on _xiprom will likely force XIP address >> + * space spawns multiple MPU regions thus it is likely we run in >> + * situation when we are reprogramming MPU region we run on with >> + * something which doesn't cover reprogramming code itself, so as soon >> + * as we update MPU settings we'd immediately try to execute straight >> + * from background region which is XN. >> + * It seem that alignment in 1M should suit most users. >> + * _exiprom is aligned as 1/8 of 1M so can be covered by subregion >> + * disable >> + */ >> +ASSERT(!(_xiprom & (SZ_1M - 1)), "XIP start address may cause MPU programming issues") >> +ASSERT(!(_exiprom & (SZ_128K - 1)), "XIP end address may cause MPU programming issues") >> +#endif >> diff --git a/arch/arm/mm/pmsa-v7.c b/arch/arm/mm/pmsa-v7.c >> index c1f1fc7..27434d7 100644 >> --- a/arch/arm/mm/pmsa-v7.c >> +++ b/arch/arm/mm/pmsa-v7.c >> @@ -7,9 +7,11 @@ >> #include <linux/bitops.h> >> #include <linux/memblock.h> >> +#include <asm/cacheflush.h> >> #include <asm/cp15.h> >> #include <asm/cputype.h> >> #include <asm/mpu.h> >> +#include <asm/sections.h> >> #include "mm.h" >> @@ -20,6 +22,9 @@ struct region { >> }; >> static struct region __initdata mem[MPU_MAX_REGIONS]; >> +#ifdef CONFIG_XIP_KERNEL >> +static struct region __initdata xip[MPU_MAX_REGIONS]; >> +#endif >> static unsigned int __initdata mpu_min_region_order; >> static unsigned int __initdata mpu_max_regions; >> @@ -229,7 +234,6 @@ static int __init allocate_region(phys_addr_t base, phys_addr_t size, >> /* MPU initialisation functions */ >> void __init adjust_lowmem_bounds_mpu(void) >> { >> - phys_addr_t phys_offset = PHYS_OFFSET; >> phys_addr_t specified_mem_size, total_mem_size = 0; >> struct memblock_region *reg; >> bool first = true; >> @@ -256,8 +260,19 @@ void __init adjust_lowmem_bounds_mpu(void) >> /* ... and one for vectors */ >> mem_max_regions--; >> #endif >> + >> +#ifdef CONFIG_XIP_KERNEL >> + /* plus some regions to cover XIP ROM */ >> + num = allocate_region(CONFIG_XIP_PHYS_ADDR, __pa(_exiprom) - CONFIG_XIP_PHYS_ADDR, >> + mem_max_regions, xip); >> + >> + mem_max_regions -= num; >> +#endif >> + >> for_each_memblock(memory, reg) { >> if (first) { >> + phys_addr_t phys_offset = PHYS_OFFSET; >> + >> /* >> * Initially only use memory continuous from >> * PHYS_OFFSET */ >> @@ -355,7 +370,7 @@ static int __init __mpu_min_region_order(void) >> static int __init mpu_setup_region(unsigned int number, phys_addr_t start, >> unsigned int size_order, unsigned int properties, >> - unsigned int subregions) >> + unsigned int subregions, bool need_flush) >> { >> u32 size_data; >> @@ -374,6 +389,9 @@ static int __init mpu_setup_region(unsigned int number, phys_addr_t start, >> size_data = ((size_order - 1) << MPU_RSR_SZ) | 1 << MPU_RSR_EN; >> size_data |= subregions << MPU_RSR_SD; >> + if (need_flush) >> + flush_cache_all(); >> + >> dsb(); /* Ensure all previous data accesses occur with old mappings */ >> rgnr_write(number); >> isb(); >> @@ -416,7 +434,28 @@ void __init mpu_setup(void) >> /* Background */ >> err |= mpu_setup_region(region++, 0, 32, >> MPU_ACR_XN | MPU_RGN_STRONGLY_ORDERED | MPU_AP_PL1RW_PL0NA, >> - 0); >> + 0, false); >> + >> +#ifdef CONFIG_XIP_KERNEL >> + /* ROM */ >> + for (i = 0; i < ARRAY_SIZE(xip); i++) { >> + /* >> + * In case we overwrite RAM region we set earlier in >> + * head-nommu.S (which is cachable) all subsequent >> + * data access till we setup RAM bellow would be done >> + * with BG region (which is uncachable), thus we need >> + * to clean and invalidate cache. >> + */ >> + bool need_flush = region == MPU_RAM_REGION; >> + >> + if (!xip[i].size) >> + continue; >> + >> + err |= mpu_setup_region(region++, xip[i].base, ilog2(xip[i].size), >> + MPU_AP_PL1RO_PL0NA | MPU_RGN_NORMAL, >> + xip[i].subreg, need_flush); >> + } >> +#endif >> /* RAM */ >> for (i = 0; i < ARRAY_SIZE(mem); i++) { >> @@ -425,14 +464,14 @@ void __init mpu_setup(void) >> err |= mpu_setup_region(region++, mem[i].base, ilog2(mem[i].size), >> MPU_AP_PL1RW_PL0RW | MPU_RGN_NORMAL, >> - mem[i].subreg); >> + mem[i].subreg, false); >> } >> /* Vectors */ >> #ifndef CONFIG_CPU_V7M >> err |= mpu_setup_region(region++, vectors_base, ilog2(2 * PAGE_SIZE), >> MPU_AP_PL1RW_PL0NA | MPU_RGN_NORMAL, >> - 0); >> + 0, false); >> #endif >> if (err) { >> panic("MPU region initialization failure! %d", err); >> >
Russell, do you have concerns on this series? Thanks Vladimir On 25/09/17 10:05, Vladimir Murzin wrote: > Hi, > > This is an update of the existent MPU code which consist set of > clean-ups and enhancements. The most significant changes are in the > way how MPU settings sync-up for secondaries (PATCH 3/8), more > flexible layout for memory (PATCH 7/8) and support for XIP (PATCH > 8/8). Since there is no in-tree user of MPU, support for M-class has > been added (PATCH 6/8). > > There is also practical benefit of patch set: > > "These MPU patches introduce a nice feature that it simplifies the > bootloader: do not need to setup the MPU, for example for coherent DMA > region, which is described in device-tree too." András Szemző > > Changelog: > v2 -> v3 > - fixed support for XIP (PATCH 8/8) > - rebased on 4.14-rc2 > > v1 -> v2 > - support for XIP (PATCH 8/8) > - rebased on 4.13-rc1 > > RFC v2 -> v1 > - dropped RFC tag > - Tested-by from András > - rebased on 4.12-rc5 > > RFC -> RFC v2 > - fixed MPU enable for v7m (PATCH 6/7) > > Thanks! > > Vladimir Murzin (8): > ARM: NOMMU: Move out MPU setup in separate module > ARM: NOMMU: Update MPU accessors to use cp15 helpers > ARM: NOMMU: Rework MPU to be mostly done in C > ARM: NOMMU: Disallow MPU for XIP > ARM: Kconfig: Kill CONFIG_VECTORS_BASE > ARM: V7M: Add support for MPU to M-class > ARM: NOMMU: Use more MPU regions to cover memory > ARM: NOMMU: Support MPU in XIP configuration > > arch/arm/Kconfig | 9 - > arch/arm/Kconfig-nommu | 4 +- > arch/arm/include/asm/cputype.h | 10 + > arch/arm/include/asm/mpu.h | 26 +- > arch/arm/include/asm/smp.h | 2 +- > arch/arm/include/asm/v7m.h | 10 + > arch/arm/kernel/asm-offsets.c | 11 + > arch/arm/kernel/head-nommu.S | 148 +++++++++--- > arch/arm/kernel/smp.c | 2 +- > arch/arm/kernel/vmlinux-xip.lds.S | 23 ++ > arch/arm/mm/Makefile | 1 + > arch/arm/mm/nommu.c | 254 +------------------- > arch/arm/mm/pmsa-v7.c | 484 ++++++++++++++++++++++++++++++++++++++ > 13 files changed, 682 insertions(+), 302 deletions(-) > create mode 100644 arch/arm/mm/pmsa-v7.c >
Gentle ping... On 09/10/17 10:20, Vladimir Murzin wrote: > Russell, do you have concerns on this series? > > Thanks > Vladimir > > On 25/09/17 10:05, Vladimir Murzin wrote: >> Hi, >> >> This is an update of the existent MPU code which consist set of >> clean-ups and enhancements. The most significant changes are in the >> way how MPU settings sync-up for secondaries (PATCH 3/8), more >> flexible layout for memory (PATCH 7/8) and support for XIP (PATCH >> 8/8). Since there is no in-tree user of MPU, support for M-class has >> been added (PATCH 6/8). >> >> There is also practical benefit of patch set: >> >> "These MPU patches introduce a nice feature that it simplifies the >> bootloader: do not need to setup the MPU, for example for coherent DMA >> region, which is described in device-tree too." András Szemző >> >> Changelog: >> v2 -> v3 >> - fixed support for XIP (PATCH 8/8) >> - rebased on 4.14-rc2 >> >> v1 -> v2 >> - support for XIP (PATCH 8/8) >> - rebased on 4.13-rc1 >> >> RFC v2 -> v1 >> - dropped RFC tag >> - Tested-by from András >> - rebased on 4.12-rc5 >> >> RFC -> RFC v2 >> - fixed MPU enable for v7m (PATCH 6/7) >> >> Thanks! >> >> Vladimir Murzin (8): >> ARM: NOMMU: Move out MPU setup in separate module >> ARM: NOMMU: Update MPU accessors to use cp15 helpers >> ARM: NOMMU: Rework MPU to be mostly done in C >> ARM: NOMMU: Disallow MPU for XIP >> ARM: Kconfig: Kill CONFIG_VECTORS_BASE >> ARM: V7M: Add support for MPU to M-class >> ARM: NOMMU: Use more MPU regions to cover memory >> ARM: NOMMU: Support MPU in XIP configuration >> >> arch/arm/Kconfig | 9 - >> arch/arm/Kconfig-nommu | 4 +- >> arch/arm/include/asm/cputype.h | 10 + >> arch/arm/include/asm/mpu.h | 26 +- >> arch/arm/include/asm/smp.h | 2 +- >> arch/arm/include/asm/v7m.h | 10 + >> arch/arm/kernel/asm-offsets.c | 11 + >> arch/arm/kernel/head-nommu.S | 148 +++++++++--- >> arch/arm/kernel/smp.c | 2 +- >> arch/arm/kernel/vmlinux-xip.lds.S | 23 ++ >> arch/arm/mm/Makefile | 1 + >> arch/arm/mm/nommu.c | 254 +------------------- >> arch/arm/mm/pmsa-v7.c | 484 ++++++++++++++++++++++++++++++++++++++ >> 13 files changed, 682 insertions(+), 302 deletions(-) >> create mode 100644 arch/arm/mm/pmsa-v7.c >> > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
Sorry, but I have no working MPS3 platform since it killed its uSD card with all the FPGA bitstreams on. I'm waiting (since end of September) for a replacement from ARM Ltd but there hasn't yet been any progress. Sure, I can replace the uSD card myself, but the problem is the contents of the card. On Fri, Oct 13, 2017 at 10:17:00AM +0100, Vladimir Murzin wrote: > Gentle ping... > > On 09/10/17 10:20, Vladimir Murzin wrote: > > Russell, do you have concerns on this series? > > > > Thanks > > Vladimir > > > > On 25/09/17 10:05, Vladimir Murzin wrote: > >> Hi, > >> > >> This is an update of the existent MPU code which consist set of > >> clean-ups and enhancements. The most significant changes are in the > >> way how MPU settings sync-up for secondaries (PATCH 3/8), more > >> flexible layout for memory (PATCH 7/8) and support for XIP (PATCH > >> 8/8). Since there is no in-tree user of MPU, support for M-class has > >> been added (PATCH 6/8). > >> > >> There is also practical benefit of patch set: > >> > >> "These MPU patches introduce a nice feature that it simplifies the > >> bootloader: do not need to setup the MPU, for example for coherent DMA > >> region, which is described in device-tree too." András Szemző > >> > >> Changelog: > >> v2 -> v3 > >> - fixed support for XIP (PATCH 8/8) > >> - rebased on 4.14-rc2 > >> > >> v1 -> v2 > >> - support for XIP (PATCH 8/8) > >> - rebased on 4.13-rc1 > >> > >> RFC v2 -> v1 > >> - dropped RFC tag > >> - Tested-by from András > >> - rebased on 4.12-rc5 > >> > >> RFC -> RFC v2 > >> - fixed MPU enable for v7m (PATCH 6/7) > >> > >> Thanks! > >> > >> Vladimir Murzin (8): > >> ARM: NOMMU: Move out MPU setup in separate module > >> ARM: NOMMU: Update MPU accessors to use cp15 helpers > >> ARM: NOMMU: Rework MPU to be mostly done in C > >> ARM: NOMMU: Disallow MPU for XIP > >> ARM: Kconfig: Kill CONFIG_VECTORS_BASE > >> ARM: V7M: Add support for MPU to M-class > >> ARM: NOMMU: Use more MPU regions to cover memory > >> ARM: NOMMU: Support MPU in XIP configuration > >> > >> arch/arm/Kconfig | 9 - > >> arch/arm/Kconfig-nommu | 4 +- > >> arch/arm/include/asm/cputype.h | 10 + > >> arch/arm/include/asm/mpu.h | 26 +- > >> arch/arm/include/asm/smp.h | 2 +- > >> arch/arm/include/asm/v7m.h | 10 + > >> arch/arm/kernel/asm-offsets.c | 11 + > >> arch/arm/kernel/head-nommu.S | 148 +++++++++--- > >> arch/arm/kernel/smp.c | 2 +- > >> arch/arm/kernel/vmlinux-xip.lds.S | 23 ++ > >> arch/arm/mm/Makefile | 1 + > >> arch/arm/mm/nommu.c | 254 +------------------- > >> arch/arm/mm/pmsa-v7.c | 484 ++++++++++++++++++++++++++++++++++++++ > >> 13 files changed, 682 insertions(+), 302 deletions(-) > >> create mode 100644 arch/arm/mm/pmsa-v7.c > >> > > > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > >
On 13/10/17 10:24, Russell King - ARM Linux wrote: > Sorry, but I have no working MPS3 platform since it killed its uSD card > with all the FPGA bitstreams on. I'm waiting (since end of September) > for a replacement from ARM Ltd but there hasn't yet been any progress. > > Sure, I can replace the uSD card myself, but the problem is the contents > of the card. Thanks for prompt reply! I should say that board won't help you with testing this series since it implements different MPU model (I have patches for that too but they are on top of this series). I've been working closely with Alex and András (since they needed this for their Cortex-M7 platform) to make sure it works as expected. It was also tested with R-class FastModels. I intentionally kept CONFIG_ARM_MPU disabled by default for M-class (PATCH 6/8), so it won't interfere with existing bootloaders. I'd be glad if you can review the series and give it a chance to sit in linux-next (I can provide a branch on top of yours for-next). Cheers Vladimir > > On Fri, Oct 13, 2017 at 10:17:00AM +0100, Vladimir Murzin wrote: >> Gentle ping... >> >> On 09/10/17 10:20, Vladimir Murzin wrote: >>> Russell, do you have concerns on this series? >>> >>> Thanks >>> Vladimir >>> >>> On 25/09/17 10:05, Vladimir Murzin wrote: >>>> Hi, >>>> >>>> This is an update of the existent MPU code which consist set of >>>> clean-ups and enhancements. The most significant changes are in the >>>> way how MPU settings sync-up for secondaries (PATCH 3/8), more >>>> flexible layout for memory (PATCH 7/8) and support for XIP (PATCH >>>> 8/8). Since there is no in-tree user of MPU, support for M-class has >>>> been added (PATCH 6/8). >>>> >>>> There is also practical benefit of patch set: >>>> >>>> "These MPU patches introduce a nice feature that it simplifies the >>>> bootloader: do not need to setup the MPU, for example for coherent DMA >>>> region, which is described in device-tree too." András Szemző >>>> >>>> Changelog: >>>> v2 -> v3 >>>> - fixed support for XIP (PATCH 8/8) >>>> - rebased on 4.14-rc2 >>>> >>>> v1 -> v2 >>>> - support for XIP (PATCH 8/8) >>>> - rebased on 4.13-rc1 >>>> >>>> RFC v2 -> v1 >>>> - dropped RFC tag >>>> - Tested-by from András >>>> - rebased on 4.12-rc5 >>>> >>>> RFC -> RFC v2 >>>> - fixed MPU enable for v7m (PATCH 6/7) >>>> >>>> Thanks! >>>> >>>> Vladimir Murzin (8): >>>> ARM: NOMMU: Move out MPU setup in separate module >>>> ARM: NOMMU: Update MPU accessors to use cp15 helpers >>>> ARM: NOMMU: Rework MPU to be mostly done in C >>>> ARM: NOMMU: Disallow MPU for XIP >>>> ARM: Kconfig: Kill CONFIG_VECTORS_BASE >>>> ARM: V7M: Add support for MPU to M-class >>>> ARM: NOMMU: Use more MPU regions to cover memory >>>> ARM: NOMMU: Support MPU in XIP configuration >>>> >>>> arch/arm/Kconfig | 9 - >>>> arch/arm/Kconfig-nommu | 4 +- >>>> arch/arm/include/asm/cputype.h | 10 + >>>> arch/arm/include/asm/mpu.h | 26 +- >>>> arch/arm/include/asm/smp.h | 2 +- >>>> arch/arm/include/asm/v7m.h | 10 + >>>> arch/arm/kernel/asm-offsets.c | 11 + >>>> arch/arm/kernel/head-nommu.S | 148 +++++++++--- >>>> arch/arm/kernel/smp.c | 2 +- >>>> arch/arm/kernel/vmlinux-xip.lds.S | 23 ++ >>>> arch/arm/mm/Makefile | 1 + >>>> arch/arm/mm/nommu.c | 254 +------------------- >>>> arch/arm/mm/pmsa-v7.c | 484 ++++++++++++++++++++++++++++++++++++++ >>>> 13 files changed, 682 insertions(+), 302 deletions(-) >>>> create mode 100644 arch/arm/mm/pmsa-v7.c >>>> >>> >>> >>> _______________________________________________ >>> linux-arm-kernel mailing list >>> linux-arm-kernel@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>> >> >
On Fri, Oct 13, 2017 at 10:40:39AM +0100, Vladimir Murzin wrote: > On 13/10/17 10:24, Russell King - ARM Linux wrote: > > Sorry, but I have no working MPS3 platform since it killed its uSD card > > with all the FPGA bitstreams on. I'm waiting (since end of September) > > for a replacement from ARM Ltd but there hasn't yet been any progress. > > > > Sure, I can replace the uSD card myself, but the problem is the contents > > of the card. > > Thanks for prompt reply! > > I should say that board won't help you with testing this series since it > implements different MPU model (I have patches for that too but they are > on top of this series). It assists as far as making sure the changes don't cause a regression for the platform. > I've been working closely with Alex and András (since they needed this for > their Cortex-M7 platform) to make sure it works as expected. It was also > tested with R-class FastModels. > > I intentionally kept CONFIG_ARM_MPU disabled by default for M-class > (PATCH 6/8), so it won't interfere with existing bootloaders. It looks like patch 6 will allow me to select ARM_MPU for the MPS3 config (by way of CPU_V7M being enabled). As I'm unable to test what effect that has here, and I don't know when I'll be able to do so, please check if not already done so. > I'd be glad if you can review the series and give it a chance to sit in > linux-next (I can provide a branch on top of yours for-next). Please never provide a branch on top of my for-next, it's an "unstable" commit in that it's regenerated from several sub-branches (fixes, misc, devel-stable, and whatever other work I want to include in linux-next.)
On 14/10/17 15:37, Russell King - ARM Linux wrote: > On Fri, Oct 13, 2017 at 10:40:39AM +0100, Vladimir Murzin wrote: >> On 13/10/17 10:24, Russell King - ARM Linux wrote: >>> Sorry, but I have no working MPS3 platform since it killed its uSD card >>> with all the FPGA bitstreams on. I'm waiting (since end of September) >>> for a replacement from ARM Ltd but there hasn't yet been any progress. >>> >>> Sure, I can replace the uSD card myself, but the problem is the contents >>> of the card. >> >> Thanks for prompt reply! >> >> I should say that board won't help you with testing this series since it >> implements different MPU model (I have patches for that too but they are >> on top of this series). > > It assists as far as making sure the changes don't cause a > regression for the platform. > >> I've been working closely with Alex and András (since they needed this for >> their Cortex-M7 platform) to make sure it works as expected. It was also >> tested with R-class FastModels. >> >> I intentionally kept CONFIG_ARM_MPU disabled by default for M-class >> (PATCH 6/8), so it won't interfere with existing bootloaders. > > It looks like patch 6 will allow me to select ARM_MPU for the MPS3 > config (by way of CPU_V7M being enabled). As I'm unable to test > what effect that has here, and I don't know when I'll be able to do > so, please check if not already done so. It was done. To ensure that there is a change in PATCH 3/8 @@ -204,13 +205,13 @@ ENTRY(__setup_mpu) mrc p15, 0, r0, c0, c1, 4 @ Read ID_MMFR0 and r0, r0, #(MMFR0_PMSA) @ PMSA field teq r0, #(MMFR0_PMSAv7) @ PMSA v7 - bne __error_p @ Fail: ARM_MPU on NOT v7 PMSA + bxne lr the C side already had a check in mpu_setup() if (!mpu_present()) return; > >> I'd be glad if you can review the series and give it a chance to sit in >> linux-next (I can provide a branch on top of yours for-next). > > Please never provide a branch on top of my for-next, it's an "unstable" > commit in that it's regenerated from several sub-branches (fixes, misc, > devel-stable, and whatever other work I want to include in linux-next.) > Ok, got it! It seems the right branch is devel-stable. Unless you have comments, I'd like to submit patches in your patch system. Thanks Vladimir
2017-09-25 11:05 GMT+02:00 Vladimir Murzin <vladimir.murzin@arm.com>: > Hi, > > This is an update of the existent MPU code which consist set of > clean-ups and enhancements. The most significant changes are in the > way how MPU settings sync-up for secondaries (PATCH 3/8), more > flexible layout for memory (PATCH 7/8) and support for XIP (PATCH > 8/8). Since there is no in-tree user of MPU, support for M-class has > been added (PATCH 6/8). > > There is also practical benefit of patch set: > > "These MPU patches introduce a nice feature that it simplifies the > bootloader: do not need to setup the MPU, for example for coherent DMA > region, which is described in device-tree too." András Szemző > > Changelog: > v2 -> v3 > - fixed support for XIP (PATCH 8/8) > - rebased on 4.14-rc2 > > v1 -> v2 > - support for XIP (PATCH 8/8) > - rebased on 4.13-rc1 > > RFC v2 -> v1 > - dropped RFC tag > - Tested-by from András > - rebased on 4.12-rc5 > > RFC -> RFC v2 > - fixed MPU enable for v7m (PATCH 6/7) > > Thanks! for the whole serie on stm32f4 and stm32f7: Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> > > Vladimir Murzin (8): > ARM: NOMMU: Move out MPU setup in separate module > ARM: NOMMU: Update MPU accessors to use cp15 helpers > ARM: NOMMU: Rework MPU to be mostly done in C > ARM: NOMMU: Disallow MPU for XIP > ARM: Kconfig: Kill CONFIG_VECTORS_BASE > ARM: V7M: Add support for MPU to M-class > ARM: NOMMU: Use more MPU regions to cover memory > ARM: NOMMU: Support MPU in XIP configuration > > arch/arm/Kconfig | 9 - > arch/arm/Kconfig-nommu | 4 +- > arch/arm/include/asm/cputype.h | 10 + > arch/arm/include/asm/mpu.h | 26 +- > arch/arm/include/asm/smp.h | 2 +- > arch/arm/include/asm/v7m.h | 10 + > arch/arm/kernel/asm-offsets.c | 11 + > arch/arm/kernel/head-nommu.S | 148 +++++++++--- > arch/arm/kernel/smp.c | 2 +- > arch/arm/kernel/vmlinux-xip.lds.S | 23 ++ > arch/arm/mm/Makefile | 1 + > arch/arm/mm/nommu.c | 254 +------------------- > arch/arm/mm/pmsa-v7.c | 484 ++++++++++++++++++++++++++++++++++++++ > 13 files changed, 682 insertions(+), 302 deletions(-) > create mode 100644 arch/arm/mm/pmsa-v7.c > > -- > 1.9.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 17/10/17 15:05, Benjamin Gaignard wrote: > 2017-09-25 11:05 GMT+02:00 Vladimir Murzin <vladimir.murzin@arm.com>: >> Hi, >> >> This is an update of the existent MPU code which consist set of >> clean-ups and enhancements. The most significant changes are in the >> way how MPU settings sync-up for secondaries (PATCH 3/8), more >> flexible layout for memory (PATCH 7/8) and support for XIP (PATCH >> 8/8). Since there is no in-tree user of MPU, support for M-class has >> been added (PATCH 6/8). >> >> There is also practical benefit of patch set: >> >> "These MPU patches introduce a nice feature that it simplifies the >> bootloader: do not need to setup the MPU, for example for coherent DMA >> region, which is described in device-tree too." András Szemző >> >> Changelog: >> v2 -> v3 >> - fixed support for XIP (PATCH 8/8) >> - rebased on 4.14-rc2 >> >> v1 -> v2 >> - support for XIP (PATCH 8/8) >> - rebased on 4.13-rc1 >> >> RFC v2 -> v1 >> - dropped RFC tag >> - Tested-by from András >> - rebased on 4.12-rc5 >> >> RFC -> RFC v2 >> - fixed MPU enable for v7m (PATCH 6/7) >> >> Thanks! > > for the whole serie on stm32f4 and stm32f7: > > Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Thanks for giving it a try! The series is already in Russell's patch system, so I dunno how to add your Tested-by, maybe Russell can made an update when he pull patches in his tree... Cheers Vladimir > >> >> Vladimir Murzin (8): >> ARM: NOMMU: Move out MPU setup in separate module >> ARM: NOMMU: Update MPU accessors to use cp15 helpers >> ARM: NOMMU: Rework MPU to be mostly done in C >> ARM: NOMMU: Disallow MPU for XIP >> ARM: Kconfig: Kill CONFIG_VECTORS_BASE >> ARM: V7M: Add support for MPU to M-class >> ARM: NOMMU: Use more MPU regions to cover memory >> ARM: NOMMU: Support MPU in XIP configuration >> >> arch/arm/Kconfig | 9 - >> arch/arm/Kconfig-nommu | 4 +- >> arch/arm/include/asm/cputype.h | 10 + >> arch/arm/include/asm/mpu.h | 26 +- >> arch/arm/include/asm/smp.h | 2 +- >> arch/arm/include/asm/v7m.h | 10 + >> arch/arm/kernel/asm-offsets.c | 11 + >> arch/arm/kernel/head-nommu.S | 148 +++++++++--- >> arch/arm/kernel/smp.c | 2 +- >> arch/arm/kernel/vmlinux-xip.lds.S | 23 ++ >> arch/arm/mm/Makefile | 1 + >> arch/arm/mm/nommu.c | 254 +------------------- >> arch/arm/mm/pmsa-v7.c | 484 ++++++++++++++++++++++++++++++++++++++ >> 13 files changed, 682 insertions(+), 302 deletions(-) >> create mode 100644 arch/arm/mm/pmsa-v7.c >> >> -- >> 1.9.1 >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > >
On Tue, Oct 17, 2017 at 03:13:36PM +0100, Vladimir Murzin wrote: > On 17/10/17 15:05, Benjamin Gaignard wrote: > > 2017-09-25 11:05 GMT+02:00 Vladimir Murzin <vladimir.murzin@arm.com>: > >> Hi, > >> > >> This is an update of the existent MPU code which consist set of > >> clean-ups and enhancements. The most significant changes are in the > >> way how MPU settings sync-up for secondaries (PATCH 3/8), more > >> flexible layout for memory (PATCH 7/8) and support for XIP (PATCH > >> 8/8). Since there is no in-tree user of MPU, support for M-class has > >> been added (PATCH 6/8). > >> > >> There is also practical benefit of patch set: > >> > >> "These MPU patches introduce a nice feature that it simplifies the > >> bootloader: do not need to setup the MPU, for example for coherent DMA > >> region, which is described in device-tree too." András Szemző > >> > >> Changelog: > >> v2 -> v3 > >> - fixed support for XIP (PATCH 8/8) > >> - rebased on 4.14-rc2 > >> > >> v1 -> v2 > >> - support for XIP (PATCH 8/8) > >> - rebased on 4.13-rc1 > >> > >> RFC v2 -> v1 > >> - dropped RFC tag > >> - Tested-by from András > >> - rebased on 4.12-rc5 > >> > >> RFC -> RFC v2 > >> - fixed MPU enable for v7m (PATCH 6/7) > >> > >> Thanks! > > > > for the whole serie on stm32f4 and stm32f7: > > > > Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> > > Thanks for giving it a try! > > The series is already in Russell's patch system, so I dunno > how to add your Tested-by, maybe Russell can made an update > when he pull patches in his tree... Applied, along with the tested-by, and with the fixup patch folded. However, I notice that with "Szemz■ András" name, the ■ character has been replaced by a "?" somewhere along the lines (and my VT console can't even display it, so (a) I've no idea what character it's supposed to be, and (b) I can't cut'n'paste it either - as illustrated by my pasting above making it come out as a rectangular block.) The problem I have is that if I push these patches out, as soon as I do, I can't fix this up, because it's the "devel-stable" branch - and the promise I make to everyone is that branch is never rebased (which is why it has the -stable suffix.) Once commits are published in that branch, they're set in stone. From what I can tell, the patches were emailed to the patch system, which means it would've gone through perl's Unicode::Map8 - internally the patch system uses UTF-8 to store the summary and description, while preserving the patch as a byte stream. Your emails to the list claim to be UTF-8, so it should've been a no-op. So, don't know what has happened, and I can't fix it at the moment, not even in the actual commits. So, I won't be pushing this out, nor will I be marking the patches as applied in the patch system until I have some kind of solution.
On Tue, Oct 17, 2017 at 03:46:56PM +0100, Russell King - ARM Linux wrote: > On Tue, Oct 17, 2017 at 03:13:36PM +0100, Vladimir Murzin wrote: > > On 17/10/17 15:05, Benjamin Gaignard wrote: > > > 2017-09-25 11:05 GMT+02:00 Vladimir Murzin <vladimir.murzin@arm.com>: > > >> Hi, > > >> > > >> This is an update of the existent MPU code which consist set of > > >> clean-ups and enhancements. The most significant changes are in the > > >> way how MPU settings sync-up for secondaries (PATCH 3/8), more > > >> flexible layout for memory (PATCH 7/8) and support for XIP (PATCH > > >> 8/8). Since there is no in-tree user of MPU, support for M-class has > > >> been added (PATCH 6/8). > > >> > > >> There is also practical benefit of patch set: > > >> > > >> "These MPU patches introduce a nice feature that it simplifies the > > >> bootloader: do not need to setup the MPU, for example for coherent DMA > > >> region, which is described in device-tree too." András Szemző > > >> > > >> Changelog: > > >> v2 -> v3 > > >> - fixed support for XIP (PATCH 8/8) > > >> - rebased on 4.14-rc2 > > >> > > >> v1 -> v2 > > >> - support for XIP (PATCH 8/8) > > >> - rebased on 4.13-rc1 > > >> > > >> RFC v2 -> v1 > > >> - dropped RFC tag > > >> - Tested-by from András > > >> - rebased on 4.12-rc5 > > >> > > >> RFC -> RFC v2 > > >> - fixed MPU enable for v7m (PATCH 6/7) > > >> > > >> Thanks! > > > > > > for the whole serie on stm32f4 and stm32f7: > > > > > > Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> > > > > Thanks for giving it a try! > > > > The series is already in Russell's patch system, so I dunno > > how to add your Tested-by, maybe Russell can made an update > > when he pull patches in his tree... > > Applied, along with the tested-by, and with the fixup patch folded. > > However, I notice that with "Szemz■ András" name, the ■ character has > been replaced by a "?" somewhere along the lines (and my VT console > can't even display it, so (a) I've no idea what character it's > supposed to be, and (b) I can't cut'n'paste it either - as illustrated > by my pasting above making it come out as a rectangular block.) > > The problem I have is that if I push these patches out, as soon as I > do, I can't fix this up, because it's the "devel-stable" branch - and > the promise I make to everyone is that branch is never rebased (which > is why it has the -stable suffix.) Once commits are published in that > branch, they're set in stone. > > From what I can tell, the patches were emailed to the patch system, > which means it would've gone through perl's Unicode::Map8 - internally > the patch system uses UTF-8 to store the summary and description, > while preserving the patch as a byte stream. Your emails to the list > claim to be UTF-8, so it should've been a no-op. So, don't know what > has happened, and I can't fix it at the moment, not even in the actual > commits. > > So, I won't be pushing this out, nor will I be marking the patches as > applied in the patch system until I have some kind of solution. Okay, seems not to be the patch system's email parsing - saving one of your messages from the list and feeding that into the mail parser gives correct results - utf-8 bytes of 0xc5 0x91, which would've been placed into mysql over a connection using utf-8 encoding. What I know is that reading it out of mysql over a utf-8 encoding gives a '?' (0x3f) for that character. What I don't know is whether it's mysql having this behaviour, or whether your message was received with the character already converted to a '?'.
On 17/10/17 15:56, Russell King - ARM Linux wrote: > On Tue, Oct 17, 2017 at 03:46:56PM +0100, Russell King - ARM Linux wrote: >> On Tue, Oct 17, 2017 at 03:13:36PM +0100, Vladimir Murzin wrote: >>> On 17/10/17 15:05, Benjamin Gaignard wrote: >>>> 2017-09-25 11:05 GMT+02:00 Vladimir Murzin <vladimir.murzin@arm.com>: >>>>> Hi, >>>>> >>>>> This is an update of the existent MPU code which consist set of >>>>> clean-ups and enhancements. The most significant changes are in the >>>>> way how MPU settings sync-up for secondaries (PATCH 3/8), more >>>>> flexible layout for memory (PATCH 7/8) and support for XIP (PATCH >>>>> 8/8). Since there is no in-tree user of MPU, support for M-class has >>>>> been added (PATCH 6/8). >>>>> >>>>> There is also practical benefit of patch set: >>>>> >>>>> "These MPU patches introduce a nice feature that it simplifies the >>>>> bootloader: do not need to setup the MPU, for example for coherent DMA >>>>> region, which is described in device-tree too." András Szemző >>>>> >>>>> Changelog: >>>>> v2 -> v3 >>>>> - fixed support for XIP (PATCH 8/8) >>>>> - rebased on 4.14-rc2 >>>>> >>>>> v1 -> v2 >>>>> - support for XIP (PATCH 8/8) >>>>> - rebased on 4.13-rc1 >>>>> >>>>> RFC v2 -> v1 >>>>> - dropped RFC tag >>>>> - Tested-by from András >>>>> - rebased on 4.12-rc5 >>>>> >>>>> RFC -> RFC v2 >>>>> - fixed MPU enable for v7m (PATCH 6/7) >>>>> >>>>> Thanks! >>>> >>>> for the whole serie on stm32f4 and stm32f7: >>>> >>>> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> >>> >>> Thanks for giving it a try! >>> >>> The series is already in Russell's patch system, so I dunno >>> how to add your Tested-by, maybe Russell can made an update >>> when he pull patches in his tree... >> >> Applied, along with the tested-by, and with the fixup patch folded. >> >> However, I notice that with "Szemz■ András" name, the ■ character has >> been replaced by a "?" somewhere along the lines (and my VT console >> can't even display it, so (a) I've no idea what character it's >> supposed to be, and (b) I can't cut'n'paste it either - as illustrated >> by my pasting above making it come out as a rectangular block.) >> >> The problem I have is that if I push these patches out, as soon as I >> do, I can't fix this up, because it's the "devel-stable" branch - and >> the promise I make to everyone is that branch is never rebased (which >> is why it has the -stable suffix.) Once commits are published in that >> branch, they're set in stone. >> >> From what I can tell, the patches were emailed to the patch system, >> which means it would've gone through perl's Unicode::Map8 - internally >> the patch system uses UTF-8 to store the summary and description, >> while preserving the patch as a byte stream. Your emails to the list >> claim to be UTF-8, so it should've been a no-op. So, don't know what >> has happened, and I can't fix it at the moment, not even in the actual >> commits. >> >> So, I won't be pushing this out, nor will I be marking the patches as >> applied in the patch system until I have some kind of solution. > > Okay, seems not to be the patch system's email parsing - saving one of > your messages from the list and feeding that into the mail parser gives > correct results - utf-8 bytes of 0xc5 0x91, which would've been placed > into mysql over a connection using utf-8 encoding. > > What I know is that reading it out of mysql over a utf-8 encoding gives > a '?' (0x3f) for that character. What I don't know is whether it's > mysql having this behaviour, or whether your message was received with > the character already converted to a '?'. > Patches where send one by one with (smtp related options are omitted) git send-email --suppress-cc=all --no-thread --to patches@armlinux.org.uk If you want I can send a patch to you directly, so you can see if it arrives converted or not. Cheers Vladimir
Hi, This is an update of the existent MPU code which consist set of clean-ups and enhancements. The most significant changes are in the way how MPU settings sync-up for secondaries (PATCH 3/8), more flexible layout for memory (PATCH 7/8) and support for XIP (PATCH 8/8). Since there is no in-tree user of MPU, support for M-class has been added (PATCH 6/8). There is also practical benefit of patch set: "These MPU patches introduce a nice feature that it simplifies the bootloader: do not need to setup the MPU, for example for coherent DMA region, which is described in device-tree too." András Szemző Changelog: v2 -> v3 - fixed support for XIP (PATCH 8/8) - rebased on 4.14-rc2 v1 -> v2 - support for XIP (PATCH 8/8) - rebased on 4.13-rc1 RFC v2 -> v1 - dropped RFC tag - Tested-by from András - rebased on 4.12-rc5 RFC -> RFC v2 - fixed MPU enable for v7m (PATCH 6/7) Thanks! Vladimir Murzin (8): ARM: NOMMU: Move out MPU setup in separate module ARM: NOMMU: Update MPU accessors to use cp15 helpers ARM: NOMMU: Rework MPU to be mostly done in C ARM: NOMMU: Disallow MPU for XIP ARM: Kconfig: Kill CONFIG_VECTORS_BASE ARM: V7M: Add support for MPU to M-class ARM: NOMMU: Use more MPU regions to cover memory ARM: NOMMU: Support MPU in XIP configuration arch/arm/Kconfig | 9 - arch/arm/Kconfig-nommu | 4 +- arch/arm/include/asm/cputype.h | 10 + arch/arm/include/asm/mpu.h | 26 +- arch/arm/include/asm/smp.h | 2 +- arch/arm/include/asm/v7m.h | 10 + arch/arm/kernel/asm-offsets.c | 11 + arch/arm/kernel/head-nommu.S | 148 +++++++++--- arch/arm/kernel/smp.c | 2 +- arch/arm/kernel/vmlinux-xip.lds.S | 23 ++ arch/arm/mm/Makefile | 1 + arch/arm/mm/nommu.c | 254 +------------------- arch/arm/mm/pmsa-v7.c | 484 ++++++++++++++++++++++++++++++++++++++ 13 files changed, 682 insertions(+), 302 deletions(-) create mode 100644 arch/arm/mm/pmsa-v7.c