* [PATCH 0/3] ARM: nommu: R-class fixes @ 2016-04-22 11:43 Vladimir Murzin 2016-04-22 11:43 ` [PATCH 1/3] ARM: nommu: fix PMSAv7 setup Vladimir Murzin ` (3 more replies) 0 siblings, 4 replies; 27+ messages in thread From: Vladimir Murzin @ 2016-04-22 11:43 UTC (permalink / raw) To: linux-arm-kernel Small set of fixes discovered with R-class cores. Jean-Philippe Brucker (2): ARM: nommu: fix PMSAv7 setup ARM: nommu: change memory reserve for the vectors Vladimir Murzin (1): ARM: domain: move {set,get}_domain under config guard arch/arm/include/asm/domain.h | 5 ++++- arch/arm/kernel/head-nommu.S | 2 +- arch/arm/mm/nommu.c | 15 ++++++++------- 3 files changed, 13 insertions(+), 9 deletions(-) -- 1.7.9.5 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 1/3] ARM: nommu: fix PMSAv7 setup 2016-04-22 11:43 [PATCH 0/3] ARM: nommu: R-class fixes Vladimir Murzin @ 2016-04-22 11:43 ` Vladimir Murzin 2016-04-22 11:43 ` [PATCH 2/3] ARM: nommu: change memory reserve for the vectors Vladimir Murzin ` (2 subsequent siblings) 3 siblings, 0 replies; 27+ messages in thread From: Vladimir Murzin @ 2016-04-22 11:43 UTC (permalink / raw) To: linux-arm-kernel From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Commit 1c2f87c (ARM: 8025/1: Get rid of meminfo) broke the support for MPU on ARMv7-R. This patch adapts the code inside CONFIG_ARM_MPU to use memblocks appropriately. MPU initialisation only uses the first memory region, and removes all subsequent ones. Because looping over all regions that need removal is inefficient, and memblock_remove already handles memory ranges, we can flatten the 'for_each_memblock' part. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> --- arch/arm/mm/nommu.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c index 1dd1093..4d113fc 100644 --- a/arch/arm/mm/nommu.c +++ b/arch/arm/mm/nommu.c @@ -87,7 +87,6 @@ static unsigned long irbar_read(void) /* MPU initialisation functions */ void __init sanity_check_meminfo_mpu(void) { - int i; phys_addr_t phys_offset = PHYS_OFFSET; phys_addr_t aligned_region_size, specified_mem_size, rounded_mem_size; struct memblock_region *reg; @@ -110,11 +109,13 @@ void __init sanity_check_meminfo_mpu(void) } else { /* * memblock auto merges contiguous blocks, remove - * all blocks afterwards + * all blocks afterwards in one go (we can't remove + * blocks separately while iterating) */ pr_notice("Ignoring RAM after %pa, memory at %pa ignored\n", - &mem_start, ®->base); - memblock_remove(reg->base, reg->size); + &mem_end, ®->base); + memblock_remove(reg->base, 0 - reg->base); + break; } } @@ -144,7 +145,7 @@ void __init sanity_check_meminfo_mpu(void) pr_warn("Truncating memory from %pa to %pa (MPU region constraints)", &specified_mem_size, &aligned_region_size); memblock_remove(mem_start + aligned_region_size, - specified_mem_size - aligned_round_size); + specified_mem_size - aligned_region_size); mem_end = mem_start + aligned_region_size; } @@ -261,7 +262,7 @@ void __init mpu_setup(void) return; region_err = mpu_setup_region(MPU_RAM_REGION, PHYS_OFFSET, - ilog2(meminfo.bank[0].size), + ilog2(memblock.memory.regions[0].size), MPU_AP_PL1RW_PL0RW | MPU_RGN_NORMAL); if (region_err) { panic("MPU region initialization failure! %d", region_err); -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH 2/3] ARM: nommu: change memory reserve for the vectors 2016-04-22 11:43 [PATCH 0/3] ARM: nommu: R-class fixes Vladimir Murzin 2016-04-22 11:43 ` [PATCH 1/3] ARM: nommu: fix PMSAv7 setup Vladimir Murzin @ 2016-04-22 11:43 ` Vladimir Murzin 2016-04-22 11:43 ` [PATCH 3/3] ARM: domain: move {set,get}_domain under config guard Vladimir Murzin 2016-04-23 6:54 ` [PATCH 0/3] ARM: nommu: R-class fixes Afzal Mohammed 3 siblings, 0 replies; 27+ messages in thread From: Vladimir Murzin @ 2016-04-22 11:43 UTC (permalink / raw) To: linux-arm-kernel From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Commit 19accfd3 (ARM: move vector stubs) moved the vector stubs in an additional page above the base vector one. This change wasn't taken into account by the nommu memreserve. This patch ensures that the kernel won't overwrite any vector stub on nommu. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> [changed the MPU side too] Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> --- arch/arm/kernel/head-nommu.S | 2 +- arch/arm/mm/nommu.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S index 9b8c5a1..fb1a69e 100644 --- a/arch/arm/kernel/head-nommu.S +++ b/arch/arm/kernel/head-nommu.S @@ -236,7 +236,7 @@ ENTRY(__setup_mpu) mov r0, #CONFIG_VECTORS_BASE @ Cover from VECTORS_BASE ldr r5,=(MPU_AP_PL1RW_PL0NA | MPU_RGN_NORMAL) /* Writing N to bits 5:1 (RSR_SZ) --> region size 2^N+1 */ - mov r6, #(((PAGE_SHIFT - 1) << MPU_RSR_SZ) | 1 << MPU_RSR_EN) + mov r6, #(((2 * PAGE_SHIFT - 1) << MPU_RSR_SZ) | 1 << MPU_RSR_EN) setup_region r0, r5, r6, MPU_DATA_SIDE @ VECTORS_BASE, PL0 NA, enabled beq 3f @ Memory-map not unified diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c index 4d113fc..d5805e4 100644 --- a/arch/arm/mm/nommu.c +++ b/arch/arm/mm/nommu.c @@ -286,7 +286,7 @@ void __init arm_mm_memblock_reserve(void) * some architectures which the DRAM is the exception vector to trap, * alloc_page breaks with error, although it is not NULL, but "0." */ - memblock_reserve(CONFIG_VECTORS_BASE, PAGE_SIZE); + memblock_reserve(CONFIG_VECTORS_BASE, 2 * PAGE_SIZE); #else /* ifndef CONFIG_CPU_V7M */ /* * There is no dedicated vector page on V7-M. So nothing needs to be -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH 3/3] ARM: domain: move {set,get}_domain under config guard 2016-04-22 11:43 [PATCH 0/3] ARM: nommu: R-class fixes Vladimir Murzin 2016-04-22 11:43 ` [PATCH 1/3] ARM: nommu: fix PMSAv7 setup Vladimir Murzin 2016-04-22 11:43 ` [PATCH 2/3] ARM: nommu: change memory reserve for the vectors Vladimir Murzin @ 2016-04-22 11:43 ` Vladimir Murzin 2016-04-27 10:49 ` [PATCH 3/3] ARM: domain: move {set, get}_domain " Russell King - ARM Linux 2016-04-23 6:54 ` [PATCH 0/3] ARM: nommu: R-class fixes Afzal Mohammed 3 siblings, 1 reply; 27+ messages in thread From: Vladimir Murzin @ 2016-04-22 11:43 UTC (permalink / raw) To: linux-arm-kernel Domains is not available on !MMU cores, like R/M class. However, currently guarding manages M-class only, for the R-class, in case of fault we get in recursive "undefined instruction" faulting because __show_regs() tries to get domain information. Fix it by extending CONFIG_CPU_USE_DOMAINS on {set,get}_domain functions and providing stubs for the case where Domains is not supported. Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> --- arch/arm/include/asm/domain.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/domain.h b/arch/arm/include/asm/domain.h index fc8ba16..a031bb9 100644 --- a/arch/arm/include/asm/domain.h +++ b/arch/arm/include/asm/domain.h @@ -84,6 +84,8 @@ #ifndef __ASSEMBLY__ +#ifdef CONFIG_CPU_USE_DOMAINS + static inline unsigned int get_domain(void) { unsigned int domain; @@ -104,7 +106,6 @@ static inline void set_domain(unsigned val) isb(); } -#ifdef CONFIG_CPU_USE_DOMAINS #define modify_domain(dom,type) \ do { \ unsigned int domain = get_domain(); \ @@ -114,6 +115,8 @@ static inline void set_domain(unsigned val) } while (0) #else +static inline unsigned int get_domain(void) { return 0;} +static inline void set_domain(unsigned val) { } static inline void modify_domain(unsigned dom, unsigned type) { } #endif -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH 3/3] ARM: domain: move {set, get}_domain under config guard 2016-04-22 11:43 ` [PATCH 3/3] ARM: domain: move {set,get}_domain under config guard Vladimir Murzin @ 2016-04-27 10:49 ` Russell King - ARM Linux 2016-04-27 12:16 ` Vladimir Murzin 0 siblings, 1 reply; 27+ messages in thread From: Russell King - ARM Linux @ 2016-04-27 10:49 UTC (permalink / raw) To: linux-arm-kernel On Fri, Apr 22, 2016 at 12:43:36PM +0100, Vladimir Murzin wrote: > Domains is not available on !MMU cores, like R/M class. However, > currently guarding manages M-class only, for the R-class, in case > of fault we get in recursive "undefined instruction" faulting because > __show_regs() tries to get domain information. > > Fix it by extending CONFIG_CPU_USE_DOMAINS on {set,get}_domain > functions and providing stubs for the case where Domains is not > supported. Huge big bloody NAK. I think it would be useful if you read the history of the file, particularly looking at commit a5e090acbf545c0a3b04080f8a488b17ec41fe02. It really amazes me how people propose patches which undo bits of previous patches without making comments about it. No way is this patch going in, which has the effect of completely disabling SW PAN, sorry. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 3/3] ARM: domain: move {set, get}_domain under config guard 2016-04-27 10:49 ` [PATCH 3/3] ARM: domain: move {set, get}_domain " Russell King - ARM Linux @ 2016-04-27 12:16 ` Vladimir Murzin 2016-04-28 13:50 ` Russell King - ARM Linux 0 siblings, 1 reply; 27+ messages in thread From: Vladimir Murzin @ 2016-04-27 12:16 UTC (permalink / raw) To: linux-arm-kernel On 27/04/16 11:49, Russell King - ARM Linux wrote: > On Fri, Apr 22, 2016 at 12:43:36PM +0100, Vladimir Murzin wrote: >> Domains is not available on !MMU cores, like R/M class. However, >> currently guarding manages M-class only, for the R-class, in case >> of fault we get in recursive "undefined instruction" faulting because >> __show_regs() tries to get domain information. >> >> Fix it by extending CONFIG_CPU_USE_DOMAINS on {set,get}_domain >> functions and providing stubs for the case where Domains is not >> supported. > > Huge big bloody NAK. > > I think it would be useful if you read the history of the file, > particularly looking at commit a5e090acbf545c0a3b04080f8a488b17ec41fe02. > > It really amazes me how people propose patches which undo bits of > previous patches without making comments about it. > > No way is this patch going in, which has the effect of completely > disabling SW PAN, sorry. > Thanks, Russell! I've confused myself that support for CPU_SW_DOMAIN_PAN implies CONFIG_CPU_USE_DOMAINS, but now I see they are in fact different features/users of those accessors. So something like below should be sufficient to fix my case, right? diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c index 4adfb46..d10c385 100644 --- a/arch/arm/kernel/process.c +++ b/arch/arm/kernel/process.c @@ -108,7 +108,7 @@ void __show_regs(struct pt_regs *regs) else domain = *(unsigned int *)(regs + 1); #else - domain = get_domain(); + domain = IS_ENABLED(CONFIG_CPU_USE_DOMAINS)? get_domain() : 0; #endif #endif Cheers Vladimir ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH 3/3] ARM: domain: move {set, get}_domain under config guard 2016-04-27 12:16 ` Vladimir Murzin @ 2016-04-28 13:50 ` Russell King - ARM Linux 2016-04-28 14:44 ` Vladimir Murzin 0 siblings, 1 reply; 27+ messages in thread From: Russell King - ARM Linux @ 2016-04-28 13:50 UTC (permalink / raw) To: linux-arm-kernel On Wed, Apr 27, 2016 at 01:16:29PM +0100, Vladimir Murzin wrote: > I've confused myself that support for CPU_SW_DOMAIN_PAN implies > CONFIG_CPU_USE_DOMAINS, but now I see they are in fact different > features/users of those accessors. > > So something like below should be sufficient to fix my case, right? How about: arch/arm/include/asm/domain.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/include/asm/domain.h b/arch/arm/include/asm/domain.h index fc8ba1663601..4e218993c12d 100644 --- a/arch/arm/include/asm/domain.h +++ b/arch/arm/include/asm/domain.h @@ -84,6 +84,7 @@ #ifndef __ASSEMBLY__ +#ifdef CONFIG_CPU_CP15 static inline unsigned int get_domain(void) { unsigned int domain; @@ -103,6 +104,16 @@ static inline void set_domain(unsigned val) : : "r" (val) : "memory"); isb(); } +#else +static inline unsigned int get_domain(void) +{ + return 0; +} + +static inline void set_domain(unsigned val) +{ +} +#endif #ifdef CONFIG_CPU_USE_DOMAINS #define modify_domain(dom,type) \ -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH 3/3] ARM: domain: move {set, get}_domain under config guard 2016-04-28 13:50 ` Russell King - ARM Linux @ 2016-04-28 14:44 ` Vladimir Murzin 2016-04-28 14:59 ` Russell King - ARM Linux 0 siblings, 1 reply; 27+ messages in thread From: Vladimir Murzin @ 2016-04-28 14:44 UTC (permalink / raw) To: linux-arm-kernel On 28/04/16 14:50, Russell King - ARM Linux wrote: > On Wed, Apr 27, 2016 at 01:16:29PM +0100, Vladimir Murzin wrote: >> I've confused myself that support for CPU_SW_DOMAIN_PAN implies >> CONFIG_CPU_USE_DOMAINS, but now I see they are in fact different >> features/users of those accessors. >> >> So something like below should be sufficient to fix my case, right? > > How about: > > arch/arm/include/asm/domain.h | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/arch/arm/include/asm/domain.h b/arch/arm/include/asm/domain.h > index fc8ba1663601..4e218993c12d 100644 > --- a/arch/arm/include/asm/domain.h > +++ b/arch/arm/include/asm/domain.h > @@ -84,6 +84,7 @@ > > #ifndef __ASSEMBLY__ > > +#ifdef CONFIG_CPU_CP15 I'm afraid it won't solve my case since R-class uses cp15 :( Cheers Vladimir > static inline unsigned int get_domain(void) > { > unsigned int domain; > @@ -103,6 +104,16 @@ static inline void set_domain(unsigned val) > : : "r" (val) : "memory"); > isb(); > } > +#else > +static inline unsigned int get_domain(void) > +{ > + return 0; > +} > + > +static inline void set_domain(unsigned val) > +{ > +} > +#endif > > #ifdef CONFIG_CPU_USE_DOMAINS > #define modify_domain(dom,type) \ > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 3/3] ARM: domain: move {set, get}_domain under config guard 2016-04-28 14:44 ` Vladimir Murzin @ 2016-04-28 14:59 ` Russell King - ARM Linux 2016-04-28 15:06 ` Vladimir Murzin 0 siblings, 1 reply; 27+ messages in thread From: Russell King - ARM Linux @ 2016-04-28 14:59 UTC (permalink / raw) To: linux-arm-kernel On Thu, Apr 28, 2016 at 03:44:34PM +0100, Vladimir Murzin wrote: > On 28/04/16 14:50, Russell King - ARM Linux wrote: > > On Wed, Apr 27, 2016 at 01:16:29PM +0100, Vladimir Murzin wrote: > >> I've confused myself that support for CPU_SW_DOMAIN_PAN implies > >> CONFIG_CPU_USE_DOMAINS, but now I see they are in fact different > >> features/users of those accessors. > >> > >> So something like below should be sufficient to fix my case, right? > > > > How about: > > > > arch/arm/include/asm/domain.h | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/arch/arm/include/asm/domain.h b/arch/arm/include/asm/domain.h > > index fc8ba1663601..4e218993c12d 100644 > > --- a/arch/arm/include/asm/domain.h > > +++ b/arch/arm/include/asm/domain.h > > @@ -84,6 +84,7 @@ > > > > #ifndef __ASSEMBLY__ > > > > +#ifdef CONFIG_CPU_CP15 > > I'm afraid it won't solve my case since R-class uses cp15 :( So maybe CPU_CP15_MMU then there? > > Cheers > Vladimir > > > static inline unsigned int get_domain(void) > > { > > unsigned int domain; > > @@ -103,6 +104,16 @@ static inline void set_domain(unsigned val) > > : : "r" (val) : "memory"); > > isb(); > > } > > +#else > > +static inline unsigned int get_domain(void) > > +{ > > + return 0; > > +} > > + > > +static inline void set_domain(unsigned val) > > +{ > > +} > > +#endif > > > > #ifdef CONFIG_CPU_USE_DOMAINS > > #define modify_domain(dom,type) \ > > > -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 3/3] ARM: domain: move {set, get}_domain under config guard 2016-04-28 14:59 ` Russell King - ARM Linux @ 2016-04-28 15:06 ` Vladimir Murzin 0 siblings, 0 replies; 27+ messages in thread From: Vladimir Murzin @ 2016-04-28 15:06 UTC (permalink / raw) To: linux-arm-kernel On 28/04/16 15:59, Russell King - ARM Linux wrote: > On Thu, Apr 28, 2016 at 03:44:34PM +0100, Vladimir Murzin wrote: >> On 28/04/16 14:50, Russell King - ARM Linux wrote: >>> On Wed, Apr 27, 2016 at 01:16:29PM +0100, Vladimir Murzin wrote: >>>> I've confused myself that support for CPU_SW_DOMAIN_PAN implies >>>> CONFIG_CPU_USE_DOMAINS, but now I see they are in fact different >>>> features/users of those accessors. >>>> >>>> So something like below should be sufficient to fix my case, right? >>> >>> How about: >>> >>> arch/arm/include/asm/domain.h | 11 +++++++++++ >>> 1 file changed, 11 insertions(+) >>> >>> diff --git a/arch/arm/include/asm/domain.h b/arch/arm/include/asm/domain.h >>> index fc8ba1663601..4e218993c12d 100644 >>> --- a/arch/arm/include/asm/domain.h >>> +++ b/arch/arm/include/asm/domain.h >>> @@ -84,6 +84,7 @@ >>> >>> #ifndef __ASSEMBLY__ >>> >>> +#ifdef CONFIG_CPU_CP15 >> >> I'm afraid it won't solve my case since R-class uses cp15 :( > > So maybe CPU_CP15_MMU then there? That should work :) Thanks Vladimir > >> >> Cheers >> Vladimir >> >>> static inline unsigned int get_domain(void) >>> { >>> unsigned int domain; >>> @@ -103,6 +104,16 @@ static inline void set_domain(unsigned val) >>> : : "r" (val) : "memory"); >>> isb(); >>> } >>> +#else >>> +static inline unsigned int get_domain(void) >>> +{ >>> + return 0; >>> +} >>> + >>> +static inline void set_domain(unsigned val) >>> +{ >>> +} >>> +#endif >>> >>> #ifdef CONFIG_CPU_USE_DOMAINS >>> #define modify_domain(dom,type) \ >>> >> > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-22 11:43 [PATCH 0/3] ARM: nommu: R-class fixes Vladimir Murzin ` (2 preceding siblings ...) 2016-04-22 11:43 ` [PATCH 3/3] ARM: domain: move {set,get}_domain under config guard Vladimir Murzin @ 2016-04-23 6:54 ` Afzal Mohammed 2016-04-25 7:55 ` Vladimir Murzin 3 siblings, 1 reply; 27+ messages in thread From: Afzal Mohammed @ 2016-04-23 6:54 UTC (permalink / raw) To: linux-arm-kernel Hi, On Fri, Apr 22, 2016 at 12:43:33PM +0100, Vladimir Murzin wrote: > Small set of fixes discovered with R-class cores. just curious, is Cortex-R supported on mainline ?, thought it was not supported, but subject & changelogs gave such a feeling. Regards afzal ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-23 6:54 ` [PATCH 0/3] ARM: nommu: R-class fixes Afzal Mohammed @ 2016-04-25 7:55 ` Vladimir Murzin 2016-04-25 12:59 ` Arnd Bergmann 0 siblings, 1 reply; 27+ messages in thread From: Vladimir Murzin @ 2016-04-25 7:55 UTC (permalink / raw) To: linux-arm-kernel On 23/04/16 07:54, Afzal Mohammed wrote: > Hi, > > On Fri, Apr 22, 2016 at 12:43:33PM +0100, Vladimir Murzin wrote: > >> Small set of fixes discovered with R-class cores. > > just curious, is Cortex-R supported on mainline ?, thought it was not > supported, but subject & changelogs gave such a feeling. Hi, I believe it is supported since c90ad5c "ARM: add Cortex-R7 Processor Info" although overtime it got blocked (at least for Vexpress) with Kconfig changes. There was attempt [1] to sort it out, but looks like these patches went nowhere, so I'm trying to re-start with the fixes coming first. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174256.html Cheers Vladimir > > Regards > afzal > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-25 7:55 ` Vladimir Murzin @ 2016-04-25 12:59 ` Arnd Bergmann 2016-04-25 13:30 ` Afzal Mohammed 2016-04-26 8:17 ` Vladimir Murzin 0 siblings, 2 replies; 27+ messages in thread From: Arnd Bergmann @ 2016-04-25 12:59 UTC (permalink / raw) To: linux-arm-kernel On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote: > On 23/04/16 07:54, Afzal Mohammed wrote: > > Hi, > > > > On Fri, Apr 22, 2016 at 12:43:33PM +0100, Vladimir Murzin wrote: > > > >> Small set of fixes discovered with R-class cores. > > > > just curious, is Cortex-R supported on mainline ?, thought it was not > > supported, but subject & changelogs gave such a feeling. > > Hi, > > I believe it is supported since c90ad5c "ARM: add Cortex-R7 Processor > Info" although overtime it got blocked (at least for Vexpress) with > Kconfig changes. There was attempt [1] to sort it out, but looks like > these patches went nowhere, so I'm trying to re-start with the fixes > coming first. > > [1] > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174256.html Good to know, thanks for working on this! What hardware platform do you use? It would be nice to make it a little more explicit which platforms can use the ARMv7-R, or an ARMv7-A with the MMU disabled. Arnd ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-25 12:59 ` Arnd Bergmann @ 2016-04-25 13:30 ` Afzal Mohammed 2016-04-26 8:17 ` Vladimir Murzin 2016-04-26 8:17 ` Vladimir Murzin 1 sibling, 1 reply; 27+ messages in thread From: Afzal Mohammed @ 2016-04-25 13:30 UTC (permalink / raw) To: linux-arm-kernel Hi, On Mon, Apr 25, 2016 at 02:59:13PM +0200, Arnd Bergmann wrote: > On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote: > What hardware platform do you use? It would be nice to make it a little > more explicit which platforms can use the ARMv7-R, or an ARMv7-A with > the MMU disabled. And for compiling user space, which toolchain is being used ? (i am quite shaky on this question, since !MMU, assuming that the normal one used for Cortex-A userspace can't be used) Regards afzal ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-25 13:30 ` Afzal Mohammed @ 2016-04-26 8:17 ` Vladimir Murzin 0 siblings, 0 replies; 27+ messages in thread From: Vladimir Murzin @ 2016-04-26 8:17 UTC (permalink / raw) To: linux-arm-kernel On 25/04/16 14:30, Afzal Mohammed wrote: > Hi, > > On Mon, Apr 25, 2016 at 02:59:13PM +0200, Arnd Bergmann wrote: >> On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote: > >> What hardware platform do you use? It would be nice to make it a little >> more explicit which platforms can use the ARMv7-R, or an ARMv7-A with >> the MMU disabled. > > And for compiling user space, which toolchain is being used ? (i am > quite shaky on this question, since !MMU, assuming that the normal one > used for Cortex-A userspace can't be used) I built myself, but there are prebild tools available at [1] although I've never tried them. It seems to me there have been internal patches to support FDPIC [2], but I don't know what happen afterwards :( [1] https://launchpad.net/gcc-arm-embedded [2] http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/ Cheers Vladimir > > Regards > afzal > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-25 12:59 ` Arnd Bergmann 2016-04-25 13:30 ` Afzal Mohammed @ 2016-04-26 8:17 ` Vladimir Murzin 2016-04-26 9:10 ` Arnd Bergmann 1 sibling, 1 reply; 27+ messages in thread From: Vladimir Murzin @ 2016-04-26 8:17 UTC (permalink / raw) To: linux-arm-kernel On 25/04/16 13:59, Arnd Bergmann wrote: > On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote: >> On 23/04/16 07:54, Afzal Mohammed wrote: >>> Hi, >>> >>> On Fri, Apr 22, 2016 at 12:43:33PM +0100, Vladimir Murzin wrote: >>> >>>> Small set of fixes discovered with R-class cores. >>> >>> just curious, is Cortex-R supported on mainline ?, thought it was not >>> supported, but subject & changelogs gave such a feeling. >> >> Hi, >> >> I believe it is supported since c90ad5c "ARM: add Cortex-R7 Processor >> Info" although overtime it got blocked (at least for Vexpress) with >> Kconfig changes. There was attempt [1] to sort it out, but looks like >> these patches went nowhere, so I'm trying to re-start with the fixes >> coming first. >> >> [1] >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174256.html > > Good to know, thanks for working on this! Since you are in a thread, just want to confirm if the following is still the right (only?) way how we want to support R-class? -----8<------- diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index a7f066e..ead2b25 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -289,8 +289,7 @@ choice config ARCH_MULTIPLATFORM bool "Allow multiple platforms to be selected" - depends on MMU - select ARM_PATCH_PHYS_VIRT + select ARM_PATCH_PHYS_VIRT if MMU select AUTO_ZRELADDR select COMMON_CLK select MULTI_IRQ_HANDLER ----->8-------- I have separate Kconfig entry to represent R-class Vexpress platform locally, but I guess it is noway, right? ;) > > What hardware platform do you use? It would be nice to make it a little > more explicit which platforms can use the ARMv7-R, or an ARMv7-A with > the MMU disabled. Currently I'm dealing mostly with ARMv7-R FVP models which represents Vexpress with R-class tile (it is why this mini series have MPU patches). I've never tried ARMv7-A with the MMU disabled and I'm quite in doubt if it is feasible. Cheers Vladimir > > Arnd > > ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-26 8:17 ` Vladimir Murzin @ 2016-04-26 9:10 ` Arnd Bergmann 2016-04-26 10:57 ` Vladimir Murzin 0 siblings, 1 reply; 27+ messages in thread From: Arnd Bergmann @ 2016-04-26 9:10 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 26 April 2016 09:17:14 Vladimir Murzin wrote: > On 25/04/16 13:59, Arnd Bergmann wrote: > > On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote: > >> On 23/04/16 07:54, Afzal Mohammed wrote: > >>> Hi, > >>> > >>> On Fri, Apr 22, 2016 at 12:43:33PM +0100, Vladimir Murzin wrote: > >>> > >>>> Small set of fixes discovered with R-class cores. > >>> > >>> just curious, is Cortex-R supported on mainline ?, thought it was not > >>> supported, but subject & changelogs gave such a feeling. > >> > >> Hi, > >> > >> I believe it is supported since c90ad5c "ARM: add Cortex-R7 Processor > >> Info" although overtime it got blocked (at least for Vexpress) with > >> Kconfig changes. There was attempt [1] to sort it out, but looks like > >> these patches went nowhere, so I'm trying to re-start with the fixes > >> coming first. > >> > >> [1] > >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174256.html > > > > Good to know, thanks for working on this! > > Since you are in a thread, just want to confirm if the following is > still the right (only?) way how we want to support R-class? > > -----8<------- > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index a7f066e..ead2b25 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -289,8 +289,7 @@ choice > > config ARCH_MULTIPLATFORM > bool "Allow multiple platforms to be selected" > - depends on MMU > - select ARM_PATCH_PHYS_VIRT > + select ARM_PATCH_PHYS_VIRT if MMU > select AUTO_ZRELADDR > select COMMON_CLK > select MULTI_IRQ_HANDLER > ----->8-------- > > I have separate Kconfig entry to represent R-class Vexpress platform > locally, but I guess it is noway, right? ;) I think we should discuss this first. It's not necessarily wrong or right, but I have taken a slightly different approach in my randconfig test tree: diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 107d2868706c..8745f84932af 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -314,9 +314,11 @@ source "kernel/Kconfig.freezer" menu "System Type" +config NOMMU + bool + config MMU - bool "MMU-based Paged Memory Management Support" - default y + def_bool !NOMMU help Select if you want MMU-based virtualised addressing space support by paged memory management. If unsure, say 'Y'. @@ -335,12 +337,10 @@ config ARCH_MMAP_RND_BITS_MAX # choice prompt "ARM system type" - default ARM_SINGLE_ARMV7M if !MMU - default ARCH_MULTIPLATFORM if MMU + default ARCH_MULTIPLATFORM config ARCH_MULTIPLATFORM bool "Allow multiple platforms to be selected" - depends on MMU select ARCH_WANT_OPTIONAL_GPIOLIB select ARM_HAS_SG_CHAIN select ARM_PATCH_PHYS_VIRT @@ -355,7 +355,6 @@ config ARCH_MULTIPLATFORM config ARM_SINGLE_ARMV7M bool "ARMv7-M based platforms (Cortex-M0/M3/M4)" - depends on !MMU select ARCH_WANT_OPTIONAL_GPIOLIB select ARM_NVIC select AUTO_ZRELADDR @@ -364,6 +363,7 @@ config ARM_SINGLE_ARMV7M select CPU_V7M select GENERIC_CLOCKEVENTS select NO_IOPORT_MAP + select NOMMU select SPARSE_IRQ select USE_OF @@ -434,7 +434,6 @@ config ARCH_NETX config ARCH_IOP13XX bool "IOP13xx-based" - depends on MMU select CPU_XSC3 select NEED_MACH_MEMORY_H select NEED_RET_TO_USER @@ -447,7 +446,6 @@ config ARCH_IOP13XX config ARCH_IOP32X bool "IOP32x-based" - depends on MMU select ARCH_REQUIRE_GPIOLIB select CPU_XSCALE select GPIO_IOP @@ -460,7 +458,6 @@ config ARCH_IOP32X config ARCH_IOP33X bool "IOP33x-based" - depends on MMU select ARCH_REQUIRE_GPIOLIB select CPU_XSCALE select GPIO_IOP @@ -472,7 +469,6 @@ config ARCH_IOP33X config ARCH_IXP4XX bool "IXP4xx-based" - depends on MMU select ARCH_HAS_DMA_SET_COHERENT_MASK select ARCH_REQUIRE_GPIOLIB select ARCH_SUPPORTS_BIG_ENDIAN @@ -531,7 +527,6 @@ config ARCH_LPC32XX config ARCH_PXA bool "PXA2xx/PXA3xx-based" - depends on MMU select ARCH_MTD_XIP select ARCH_REQUIRE_GPIOLIB select ARM_CPU_SUSPEND if PM @@ -554,7 +549,6 @@ config ARCH_PXA config ARCH_RPC bool "RiscPC" - depends on MMU select ARCH_ACORN select ARCH_MAY_HAVE_PC_FDC select ARCH_SPARSEMEM_ENABLE @@ -629,7 +623,6 @@ config ARCH_DAVINCI config ARCH_OMAP1 bool "TI OMAP1" - depends on MMU select ARCH_HAS_HOLES_MEMORYMODEL select ARCH_OMAP select ARCH_REQUIRE_GPIOLIB The main question here is how explicit we want to make the selection of MMU support per platform. Today, CONFIG_MMU is a top-level option that decides which platforms are visible, based on whether they can work with or without an MMU or both. This works fine, but means we probably have to add a lot of 'depends on MMU' with your patch to all the platforms that we want to only build with MMU enabled for some reason. Turning it around would limit the platforms to the ones that explictly turn on NOMMU support. In order to make ARMv7-R support work, we need either another top-level platform option next to ARCH_MULTIPLATFORM and ARM_SINGLE_ARMV7M, or add ARMv7-R in the CPU selection phase as an alternative to ARMv4/5 and ARMv6/7-A. > > What hardware platform do you use? It would be nice to make it a little > > more explicit which platforms can use the ARMv7-R, or an ARMv7-A with > > the MMU disabled. > > Currently I'm dealing mostly with ARMv7-R FVP models which represents > Vexpress with R-class tile (it is why this mini series have MPU > patches). I've never tried ARMv7-A with the MMU disabled and I'm quite > in doubt if it is feasible. What is the difference? I always assumed that ARMv7-R and ARMv7-A are sufficiently close that you can run the same kernel on both as long as you use neither the MMU nor the MPU. The other question here is the usefulness of doing it. I think it would be mainly used for testing, as real Cortex-R type CPUs are rather rare, but a lot of people have cheap ARMv7-A hardware that they can use for testing NOMMU kernels if they want to. Arnd ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-26 9:10 ` Arnd Bergmann @ 2016-04-26 10:57 ` Vladimir Murzin 2016-04-26 11:59 ` Arnd Bergmann 0 siblings, 1 reply; 27+ messages in thread From: Vladimir Murzin @ 2016-04-26 10:57 UTC (permalink / raw) To: linux-arm-kernel On 26/04/16 10:10, Arnd Bergmann wrote: > On Tuesday 26 April 2016 09:17:14 Vladimir Murzin wrote: >> On 25/04/16 13:59, Arnd Bergmann wrote: >>> On Monday 25 April 2016 08:55:57 Vladimir Murzin wrote: >>>> On 23/04/16 07:54, Afzal Mohammed wrote: >>>>> Hi, >>>>> >>>>> On Fri, Apr 22, 2016 at 12:43:33PM +0100, Vladimir Murzin wrote: >>>>> >>>>>> Small set of fixes discovered with R-class cores. >>>>> >>>>> just curious, is Cortex-R supported on mainline ?, thought it was not >>>>> supported, but subject & changelogs gave such a feeling. >>>> >>>> Hi, >>>> >>>> I believe it is supported since c90ad5c "ARM: add Cortex-R7 Processor >>>> Info" although overtime it got blocked (at least for Vexpress) with >>>> Kconfig changes. There was attempt [1] to sort it out, but looks like >>>> these patches went nowhere, so I'm trying to re-start with the fixes >>>> coming first. >>>> >>>> [1] >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174256.html >>> >>> Good to know, thanks for working on this! >> >> Since you are in a thread, just want to confirm if the following is >> still the right (only?) way how we want to support R-class? >> >> -----8<------- >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index a7f066e..ead2b25 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -289,8 +289,7 @@ choice >> >> config ARCH_MULTIPLATFORM >> bool "Allow multiple platforms to be selected" >> - depends on MMU >> - select ARM_PATCH_PHYS_VIRT >> + select ARM_PATCH_PHYS_VIRT if MMU >> select AUTO_ZRELADDR >> select COMMON_CLK >> select MULTI_IRQ_HANDLER >> ----->8-------- >> >> I have separate Kconfig entry to represent R-class Vexpress platform >> locally, but I guess it is noway, right? ;) > > I think we should discuss this first. It's not necessarily wrong I'm open ;) > or right, but I have taken a slightly different approach in my > randconfig test tree: > I'll play with this, thanks! > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 107d2868706c..8745f84932af 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -314,9 +314,11 @@ source "kernel/Kconfig.freezer" > > menu "System Type" > > +config NOMMU > + bool > + > config MMU > - bool "MMU-based Paged Memory Management Support" > - default y > + def_bool !NOMMU > help > Select if you want MMU-based virtualised addressing space > support by paged memory management. If unsure, say 'Y'. > @@ -335,12 +337,10 @@ config ARCH_MMAP_RND_BITS_MAX > # > choice > prompt "ARM system type" > - default ARM_SINGLE_ARMV7M if !MMU > - default ARCH_MULTIPLATFORM if MMU > + default ARCH_MULTIPLATFORM > > config ARCH_MULTIPLATFORM > bool "Allow multiple platforms to be selected" > - depends on MMU > select ARCH_WANT_OPTIONAL_GPIOLIB > select ARM_HAS_SG_CHAIN > select ARM_PATCH_PHYS_VIRT > @@ -355,7 +355,6 @@ config ARCH_MULTIPLATFORM > > config ARM_SINGLE_ARMV7M > bool "ARMv7-M based platforms (Cortex-M0/M3/M4)" > - depends on !MMU > select ARCH_WANT_OPTIONAL_GPIOLIB > select ARM_NVIC > select AUTO_ZRELADDR > @@ -364,6 +363,7 @@ config ARM_SINGLE_ARMV7M > select CPU_V7M > select GENERIC_CLOCKEVENTS > select NO_IOPORT_MAP > + select NOMMU > select SPARSE_IRQ > select USE_OF > > @@ -434,7 +434,6 @@ config ARCH_NETX > > config ARCH_IOP13XX > bool "IOP13xx-based" > - depends on MMU > select CPU_XSC3 > select NEED_MACH_MEMORY_H > select NEED_RET_TO_USER > @@ -447,7 +446,6 @@ config ARCH_IOP13XX > > config ARCH_IOP32X > bool "IOP32x-based" > - depends on MMU > select ARCH_REQUIRE_GPIOLIB > select CPU_XSCALE > select GPIO_IOP > @@ -460,7 +458,6 @@ config ARCH_IOP32X > > config ARCH_IOP33X > bool "IOP33x-based" > - depends on MMU > select ARCH_REQUIRE_GPIOLIB > select CPU_XSCALE > select GPIO_IOP > @@ -472,7 +469,6 @@ config ARCH_IOP33X > > config ARCH_IXP4XX > bool "IXP4xx-based" > - depends on MMU > select ARCH_HAS_DMA_SET_COHERENT_MASK > select ARCH_REQUIRE_GPIOLIB > select ARCH_SUPPORTS_BIG_ENDIAN > @@ -531,7 +527,6 @@ config ARCH_LPC32XX > > config ARCH_PXA > bool "PXA2xx/PXA3xx-based" > - depends on MMU > select ARCH_MTD_XIP > select ARCH_REQUIRE_GPIOLIB > select ARM_CPU_SUSPEND if PM > @@ -554,7 +549,6 @@ config ARCH_PXA > > config ARCH_RPC > bool "RiscPC" > - depends on MMU > select ARCH_ACORN > select ARCH_MAY_HAVE_PC_FDC > select ARCH_SPARSEMEM_ENABLE > @@ -629,7 +623,6 @@ config ARCH_DAVINCI > > config ARCH_OMAP1 > bool "TI OMAP1" > - depends on MMU > select ARCH_HAS_HOLES_MEMORYMODEL > select ARCH_OMAP > select ARCH_REQUIRE_GPIOLIB > > The main question here is how explicit we want to make the selection > of MMU support per platform. Today, CONFIG_MMU is a top-level option > that decides which platforms are visible, based on whether they can > work with or without an MMU or both. > > This works fine, but means we probably have to add a lot of 'depends > on MMU' with your patch to all the platforms that we want to only build > with MMU enabled for some reason. I've just checked my local branch and it seems not much "depend on" (although I'm not dare to claim randconfig stays happy with that), but some noMMU stubs and a few Kconfig changes across platform. > > Turning it around would limit the platforms to the ones that > explictly turn on NOMMU support. In order to make ARMv7-R support > work, we need either another top-level platform option next to > ARCH_MULTIPLATFORM and ARM_SINGLE_ARMV7M, or add ARMv7-R in > the CPU selection phase as an alternative to ARMv4/5 and ARMv6/7-A. > It depends if we what NOMMU represented (apart from M-class) R-class only or R-class + A-class without MMU. >>> What hardware platform do you use? It would be nice to make it a little >>> more explicit which platforms can use the ARMv7-R, or an ARMv7-A with >>> the MMU disabled. >> >> Currently I'm dealing mostly with ARMv7-R FVP models which represents >> Vexpress with R-class tile (it is why this mini series have MPU >> patches). I've never tried ARMv7-A with the MMU disabled and I'm quite >> in doubt if it is feasible. > > What is the difference? I always assumed that ARMv7-R and ARMv7-A are > sufficiently close that you can run the same kernel on both as long > as you use neither the MMU nor the MPU. Right they are quite close and shares a lot of code except MMU and MPU, and I'd think without MMU/MPU such configurations are limited with UP only. I've not though of such option before, so I'd need to try and see. On the other hand assumption that NOMMU == ARMv7-A - MMU, makes me think that any ARMv7 platform should be available for selection if CONFIG_MMU is deselected. At least such approach gives better build coverage and if there are platforms which suffer from such assumption runtime they can be guarded with COMPILE_TEST. > The other question here is the usefulness of doing it. I think it would > be mainly used for testing, as real Cortex-R type CPUs are rather rare, > but a lot of people have cheap ARMv7-A hardware that they can use for > testing NOMMU kernels if they want to. Yes, Cortex-R is extremely rare, it is why I've looked at another alternative - reuse R-class features (MPU only at the moment) from the feature-closest M-class - MPU got unlocked for M-class in the same way as it's done for caches [1]. [1] http://www.spinics.net/lists/arm-kernel/msg498910.html > > Arnd > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-26 10:57 ` Vladimir Murzin @ 2016-04-26 11:59 ` Arnd Bergmann 2016-04-26 12:24 ` Vladimir Murzin 2016-04-26 15:23 ` Afzal Mohammed 0 siblings, 2 replies; 27+ messages in thread From: Arnd Bergmann @ 2016-04-26 11:59 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote: > On 26/04/16 10:10, Arnd Bergmann wrote: > > On Tuesday 26 April 2016 09:17:14 Vladimir Murzin wrote: > > Turning it around would limit the platforms to the ones that > > explictly turn on NOMMU support. In order to make ARMv7-R support > > work, we need either another top-level platform option next to > > ARCH_MULTIPLATFORM and ARM_SINGLE_ARMV7M, or add ARMv7-R in > > the CPU selection phase as an alternative to ARMv4/5 and ARMv6/7-A. > > > > It depends if we what NOMMU represented (apart from M-class) R-class > only or R-class + A-class without MMU. Exactly. The same is of course true for the older architectures: There are tons of ARM7TDMI, ARM946, ARM1156 or Marvell Feroceon cores without MMU, but we don't currently support any of them with an upstream kernel. Respectively, we should in theory be able to run on any of the other MMU based cores that we do support (ARM720T, StrongARM, ARM92x, ARM1136/1176/MPCore, ...) with the MMU disabled, but neither of the two scenarios seems interesting for mainline kernels in this age any more. What we know is that ARMv7-M is widely used, ARMv7-R makes a lot of sense to use, and there are probably use cases for ARMv7-A without MMU. > >>> What hardware platform do you use? It would be nice to make it a little > >>> more explicit which platforms can use the ARMv7-R, or an ARMv7-A with > >>> the MMU disabled. > >> > >> Currently I'm dealing mostly with ARMv7-R FVP models which represents > >> Vexpress with R-class tile (it is why this mini series have MPU > >> patches). I've never tried ARMv7-A with the MMU disabled and I'm quite > >> in doubt if it is feasible. > > > > What is the difference? I always assumed that ARMv7-R and ARMv7-A are > > sufficiently close that you can run the same kernel on both as long > > as you use neither the MMU nor the MPU. > > Right they are quite close and shares a lot of code except MMU and MPU, > and I'd think without MMU/MPU such configurations are limited with UP > only. I've not though of such option before, so I'd need to try and see. > > On the other hand assumption that NOMMU == ARMv7-A - MMU, makes me think > that any ARMv7 platform should be available for selection if CONFIG_MMU > is deselected. At least such approach gives better build coverage and if > there are platforms which suffer from such assumption runtime they can > be guarded with COMPILE_TEST. I think one problem is that with MMU disabled ARMv7-A, you implicitly disable the caches and that is probably what you are thinking of for SMP support as well (atomic instructions need caches). However, this can be worked around using a static page table set up at boot time that creates hugepage entries with appropriate flags for RAM and I/O areas. If we ever had a usecase for running this setup in production, we could even fake an MPU that way. Arnd ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-26 11:59 ` Arnd Bergmann @ 2016-04-26 12:24 ` Vladimir Murzin 2016-04-26 18:12 ` Arnd Bergmann 2016-04-26 15:23 ` Afzal Mohammed 1 sibling, 1 reply; 27+ messages in thread From: Vladimir Murzin @ 2016-04-26 12:24 UTC (permalink / raw) To: linux-arm-kernel On 26/04/16 12:59, Arnd Bergmann wrote: > On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote: >> On 26/04/16 10:10, Arnd Bergmann wrote: >>> On Tuesday 26 April 2016 09:17:14 Vladimir Murzin wrote: > >>> Turning it around would limit the platforms to the ones that >>> explictly turn on NOMMU support. In order to make ARMv7-R support >>> work, we need either another top-level platform option next to >>> ARCH_MULTIPLATFORM and ARM_SINGLE_ARMV7M, or add ARMv7-R in >>> the CPU selection phase as an alternative to ARMv4/5 and ARMv6/7-A. >>> >> >> It depends if we what NOMMU represented (apart from M-class) R-class >> only or R-class + A-class without MMU. > > Exactly. The same is of course true for the older architectures: > There are tons of ARM7TDMI, ARM946, ARM1156 or Marvell Feroceon cores > without MMU, but we don't currently support any of them with an > upstream kernel. Respectively, we should in theory be able to > run on any of the other MMU based cores that we do support (ARM720T, > StrongARM, ARM92x, ARM1136/1176/MPCore, ...) with the MMU disabled, > but neither of the two scenarios seems interesting for mainline > kernels in this age any more. > > What we know is that ARMv7-M is widely used, ARMv7-R makes a lot of > sense to use, and there are probably use cases for ARMv7-A without > MMU. > >>>>> What hardware platform do you use? It would be nice to make it a little >>>>> more explicit which platforms can use the ARMv7-R, or an ARMv7-A with >>>>> the MMU disabled. >>>> >>>> Currently I'm dealing mostly with ARMv7-R FVP models which represents >>>> Vexpress with R-class tile (it is why this mini series have MPU >>>> patches). I've never tried ARMv7-A with the MMU disabled and I'm quite >>>> in doubt if it is feasible. >>> >>> What is the difference? I always assumed that ARMv7-R and ARMv7-A are >>> sufficiently close that you can run the same kernel on both as long >>> as you use neither the MMU nor the MPU. >> >> Right they are quite close and shares a lot of code except MMU and MPU, >> and I'd think without MMU/MPU such configurations are limited with UP >> only. I've not though of such option before, so I'd need to try and see. >> >> On the other hand assumption that NOMMU == ARMv7-A - MMU, makes me think >> that any ARMv7 platform should be available for selection if CONFIG_MMU >> is deselected. At least such approach gives better build coverage and if >> there are platforms which suffer from such assumption runtime they can >> be guarded with COMPILE_TEST. > > I think one problem is that with MMU disabled ARMv7-A, you implicitly > disable the caches and that is probably what you are thinking of for > SMP support as well (atomic instructions need caches). Another problem is that we need to provide DRAM_BASE and DRAM_SIZE for such builds, but it can be addressed with 1:1 mappings you've described below > > However, this can be worked around using a static page table set up > at boot time that creates hugepage entries with appropriate flags for > RAM and I/O areas. If we ever had a usecase for running this setup > in production, we could even fake an MPU that way. I'd think that support for FDPIC would make it one step closer. I conclude that we don't want dedicated option for R-class cores and we start from assumption that NOMMU covers: M-, R- and A- (without MMU or 1:1 mapping) cores. Please, correct me. Vladimir > Arnd > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-26 12:24 ` Vladimir Murzin @ 2016-04-26 18:12 ` Arnd Bergmann 2016-04-27 9:10 ` Vladimir Murzin 0 siblings, 1 reply; 27+ messages in thread From: Arnd Bergmann @ 2016-04-26 18:12 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 26 April 2016 13:24:38 Vladimir Murzin wrote: > On 26/04/16 12:59, Arnd Bergmann wrote: > > On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote: > >> On 26/04/16 10:10, Arnd Bergmann wrote: > >>>>> What hardware platform do you use? It would be nice to make it a little > >>>>> more explicit which platforms can use the ARMv7-R, or an ARMv7-A with > >>>>> the MMU disabled. > >>>> > >>>> Currently I'm dealing mostly with ARMv7-R FVP models which represents > >>>> Vexpress with R-class tile (it is why this mini series have MPU > >>>> patches). I've never tried ARMv7-A with the MMU disabled and I'm quite > >>>> in doubt if it is feasible. > >>> > >>> What is the difference? I always assumed that ARMv7-R and ARMv7-A are > >>> sufficiently close that you can run the same kernel on both as long > >>> as you use neither the MMU nor the MPU. > >> > >> Right they are quite close and shares a lot of code except MMU and MPU, > >> and I'd think without MMU/MPU such configurations are limited with UP > >> only. I've not though of such option before, so I'd need to try and see. > >> > >> On the other hand assumption that NOMMU == ARMv7-A - MMU, makes me think > >> that any ARMv7 platform should be available for selection if CONFIG_MMU > >> is deselected. At least such approach gives better build coverage and if > >> there are platforms which suffer from such assumption runtime they can > >> be guarded with COMPILE_TEST. > > > > I think one problem is that with MMU disabled ARMv7-A, you implicitly > > disable the caches and that is probably what you are thinking of for > > SMP support as well (atomic instructions need caches). > > Another problem is that we need to provide DRAM_BASE and DRAM_SIZE for > such builds, but it can be addressed with 1:1 mappings you've described > below But that's not any different between ARMv7-A and ARMv7-R, right? > > However, this can be worked around using a static page table set up > > at boot time that creates hugepage entries with appropriate flags for > > RAM and I/O areas. If we ever had a usecase for running this setup > > in production, we could even fake an MPU that way. > > I'd think that support for FDPIC would make it one step closer. Yes, that would be very useful. > I conclude that we don't want dedicated option for R-class cores and we > start from assumption that NOMMU covers: M-, R- and A- (without MMU or > 1:1 mapping) cores. Please, correct me. I'm still undecided on that. On the one hand it would be nice to support building a kernel that can run on both ARMv7-A and ARMv7-R, especially when you are talking about pluggable CPU modules on the same baseboard in case of RealView and Versatile Express. On the other hand, separating the two has the advantage of keeping it simple, as we don't have to worry about all the ARMv7-A platforms and whether we actually want to allow their kernels to be built with MMU disabled. Arnd ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-26 18:12 ` Arnd Bergmann @ 2016-04-27 9:10 ` Vladimir Murzin 2016-04-27 9:50 ` Arnd Bergmann 0 siblings, 1 reply; 27+ messages in thread From: Vladimir Murzin @ 2016-04-27 9:10 UTC (permalink / raw) To: linux-arm-kernel On 26/04/16 19:12, Arnd Bergmann wrote: > On Tuesday 26 April 2016 13:24:38 Vladimir Murzin wrote: >> On 26/04/16 12:59, Arnd Bergmann wrote: >>> On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote: >>>> On 26/04/16 10:10, Arnd Bergmann wrote: >>>>>>> What hardware platform do you use? It would be nice to make it a little >>>>>>> more explicit which platforms can use the ARMv7-R, or an ARMv7-A with >>>>>>> the MMU disabled. >>>>>> >>>>>> Currently I'm dealing mostly with ARMv7-R FVP models which represents >>>>>> Vexpress with R-class tile (it is why this mini series have MPU >>>>>> patches). I've never tried ARMv7-A with the MMU disabled and I'm quite >>>>>> in doubt if it is feasible. >>>>> >>>>> What is the difference? I always assumed that ARMv7-R and ARMv7-A are >>>>> sufficiently close that you can run the same kernel on both as long >>>>> as you use neither the MMU nor the MPU. >>>> >>>> Right they are quite close and shares a lot of code except MMU and MPU, >>>> and I'd think without MMU/MPU such configurations are limited with UP >>>> only. I've not though of such option before, so I'd need to try and see. >>>> >>>> On the other hand assumption that NOMMU == ARMv7-A - MMU, makes me think >>>> that any ARMv7 platform should be available for selection if CONFIG_MMU >>>> is deselected. At least such approach gives better build coverage and if >>>> there are platforms which suffer from such assumption runtime they can >>>> be guarded with COMPILE_TEST. >>> >>> I think one problem is that with MMU disabled ARMv7-A, you implicitly >>> disable the caches and that is probably what you are thinking of for >>> SMP support as well (atomic instructions need caches). >> >> Another problem is that we need to provide DRAM_BASE and DRAM_SIZE for >> such builds, but it can be addressed with 1:1 mappings you've described >> below > > But that's not any different between ARMv7-A and ARMv7-R, right? Right, but it'd make sort of feeling "as soon as I disable MMU it stops booting" for ARMv7-A where for ARMv7-R it likely won't boot till these parameters supplied. However, it is not a show stopper, just a reminder that extra configuration step might be needed. > >>> However, this can be worked around using a static page table set up >>> at boot time that creates hugepage entries with appropriate flags for >>> RAM and I/O areas. If we ever had a usecase for running this setup >>> in production, we could even fake an MPU that way. >> >> I'd think that support for FDPIC would make it one step closer. > > Yes, that would be very useful. > >> I conclude that we don't want dedicated option for R-class cores and we >> start from assumption that NOMMU covers: M-, R- and A- (without MMU or >> 1:1 mapping) cores. Please, correct me. > > I'm still undecided on that. On the one hand it would be nice to support > building a kernel that can run on both ARMv7-A and ARMv7-R, especially > when you are talking about pluggable CPU modules on the same baseboard > in case of RealView and Versatile Express. > > On the other hand, separating the two has the advantage of keeping it > simple, as we don't have to worry about all the ARMv7-A platforms > and whether we actually want to allow their kernels to be built with > MMU disabled. > Ok, what if we start with your approach explicitly saying which platform wants to be listed when CONFIG_MMU is deselected (I think R-class is the first user here) gradually extending such list with ARMv7-A? There is (little?) chance that at some point we can support kernel which can run on both configurations. Vladimir > Arnd > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-27 9:10 ` Vladimir Murzin @ 2016-04-27 9:50 ` Arnd Bergmann 2016-04-27 10:55 ` Vladimir Murzin 0 siblings, 1 reply; 27+ messages in thread From: Arnd Bergmann @ 2016-04-27 9:50 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 27 April 2016 10:10:19 Vladimir Murzin wrote: > > On the other hand, separating the two has the advantage of keeping it > > simple, as we don't have to worry about all the ARMv7-A platforms > > and whether we actually want to allow their kernels to be built with > > MMU disabled. > > > > Ok, what if we start with your approach explicitly saying which platform > wants to be listed when CONFIG_MMU is deselected (I think R-class is the > first user here) gradually extending such list with ARMv7-A? There is > (little?) chance that at some point we can support kernel which can run > on both configurations. Do you mean adding a ARM_SINGLE_ARMV7R option, or ARCH_MULTI_V7R? Arnd ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-27 9:50 ` Arnd Bergmann @ 2016-04-27 10:55 ` Vladimir Murzin 2016-04-27 11:18 ` Arnd Bergmann 0 siblings, 1 reply; 27+ messages in thread From: Vladimir Murzin @ 2016-04-27 10:55 UTC (permalink / raw) To: linux-arm-kernel On 27/04/16 10:50, Arnd Bergmann wrote: > On Wednesday 27 April 2016 10:10:19 Vladimir Murzin wrote: >>> On the other hand, separating the two has the advantage of keeping it >>> simple, as we don't have to worry about all the ARMv7-A platforms >>> and whether we actually want to allow their kernels to be built with >>> MMU disabled. >>> >> >> Ok, what if we start with your approach explicitly saying which platform >> wants to be listed when CONFIG_MMU is deselected (I think R-class is the >> first user here) gradually extending such list with ARMv7-A? There is >> (little?) chance that at some point we can support kernel which can run >> on both configurations. > > Do you mean adding a ARM_SINGLE_ARMV7R option, or ARCH_MULTI_V7R? I'd think that ARCH_MULTI_V7R would make more sense since it is close rather to the CPU variant than platform, so for the imaginary case where ARMv7-A platform want to run without MMU can adjust it's dependency to depends on ARCH_MULTI_V7 || ARCH_MULTI_V7R where config ARCH_MULTI_V7 bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)" depends on MMU ... config ARCH_MULTI_V7R bool "MMU-less ARMv7 based platforms (Cortex-R)" depends on !MMU ... It is also should work for purely R-class platform, although I'm not keen on Kconfig and may be totally wrong here :( Cheers Vladimir > > Arnd > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-27 10:55 ` Vladimir Murzin @ 2016-04-27 11:18 ` Arnd Bergmann 0 siblings, 0 replies; 27+ messages in thread From: Arnd Bergmann @ 2016-04-27 11:18 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 27 April 2016 11:55:12 Vladimir Murzin wrote: > ARMv7-A platform want to run without MMU can adjust it's dependency to > > depends on ARCH_MULTI_V7 || ARCH_MULTI_V7R > > where > > config ARCH_MULTI_V7 > bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)" > depends on MMU > ... > > config ARCH_MULTI_V7R > bool "MMU-less ARMv7 based platforms (Cortex-R)" > depends on !MMU > ... > > It is also should work for purely R-class platform, although I'm not > keen on Kconfig and may be totally wrong here I would not use "depends on ARCH_MULTI_V7 || ARCH_MULTI_V7R" for a machine that actually has an ARMv7-A core, that would be a bit confusing. If we want to allow building a kernel for ARMv7-A with MMU disabled, I'd drop the 'depends on MMU' for ARCH_MULTI_V7 and move it to whatever parts of the kernel actually have a build-time dependency or that are known to be broken in that configuration. Arnd ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-26 11:59 ` Arnd Bergmann 2016-04-26 12:24 ` Vladimir Murzin @ 2016-04-26 15:23 ` Afzal Mohammed 2016-04-28 9:41 ` Maxime Coquelin 1 sibling, 1 reply; 27+ messages in thread From: Afzal Mohammed @ 2016-04-26 15:23 UTC (permalink / raw) To: linux-arm-kernel Hi, On Tue, Apr 26, 2016 at 09:17:43AM +0100, Vladimir Murzin wrote: > I built myself, but there are prebild tools available at [1] although > I've never tried them. > > It seems to me there have been internal patches to support FDPIC [2], > but I don't know what happen afterwards :( > > [1] https://launchpad.net/gcc-arm-embedded > [2] > http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/ Thank You, [2] gave some indigestion :), will take some to ... On Tue, Apr 26, 2016 at 01:59:57PM +0200, Arnd Bergmann wrote: > On Tuesday 26 April 2016 11:57:38 Vladimir Murzin wrote: > and there are probably use cases for ARMv7-A without MMU. My regular work is motor control related that uses RTOS, there was a potential customer asking about running it with MMU, caches disabled on A9. Probably the reason being they considering guranteed worst case performance w/ caches enabled similar to that w/ caches disabled, though that requirement was not in Linux. > > Right they are quite close and shares a lot of code except MMU and MPU, > > and I'd think without MMU/MPU such configurations are limited with UP > I think one problem is that with MMU disabled ARMv7-A, you implicitly > disable the caches and that is probably what you are thinking of for > SMP support as well (atomic instructions need caches). Have once tried to compile ARMv7-A w/o MMU, got entangled in a web of Kconfig dependencies, iirc one among them was that with !MMU, MULTI_V7 platforms (AM335x, Vybrid A5 part) couldn't be selected, probably because of SMP dependency, but that was on a older Kernel version. Regards afzal ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] ARM: nommu: R-class fixes 2016-04-26 15:23 ` Afzal Mohammed @ 2016-04-28 9:41 ` Maxime Coquelin 0 siblings, 0 replies; 27+ messages in thread From: Maxime Coquelin @ 2016-04-28 9:41 UTC (permalink / raw) To: linux-arm-kernel Hi, On 04/26/2016 05:23 PM, Afzal Mohammed wrote: > Hi, > > On Tue, Apr 26, 2016 at 09:17:43AM +0100, Vladimir Murzin wrote: > >> I built myself, but there are prebild tools available at [1] although >> I've never tried them. >> >> It seems to me there have been internal patches to support FDPIC [2], >> but I don't know what happen afterwards :( >> >> [1] https://launchpad.net/gcc-arm-embedded >> [2] >> http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/ >> The ARM FDPIC port is done by Mickael Guene (Added in cc:). His work is available on github: - abi : https://github.com/mickael-guene/fdpic_doc - general info : https://github.com/mickael-guene/fdpic_manifest If you want more details, don't hesitate to contact him. Regards, Maxime ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2016-04-28 15:06 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-04-22 11:43 [PATCH 0/3] ARM: nommu: R-class fixes Vladimir Murzin 2016-04-22 11:43 ` [PATCH 1/3] ARM: nommu: fix PMSAv7 setup Vladimir Murzin 2016-04-22 11:43 ` [PATCH 2/3] ARM: nommu: change memory reserve for the vectors Vladimir Murzin 2016-04-22 11:43 ` [PATCH 3/3] ARM: domain: move {set,get}_domain under config guard Vladimir Murzin 2016-04-27 10:49 ` [PATCH 3/3] ARM: domain: move {set, get}_domain " Russell King - ARM Linux 2016-04-27 12:16 ` Vladimir Murzin 2016-04-28 13:50 ` Russell King - ARM Linux 2016-04-28 14:44 ` Vladimir Murzin 2016-04-28 14:59 ` Russell King - ARM Linux 2016-04-28 15:06 ` Vladimir Murzin 2016-04-23 6:54 ` [PATCH 0/3] ARM: nommu: R-class fixes Afzal Mohammed 2016-04-25 7:55 ` Vladimir Murzin 2016-04-25 12:59 ` Arnd Bergmann 2016-04-25 13:30 ` Afzal Mohammed 2016-04-26 8:17 ` Vladimir Murzin 2016-04-26 8:17 ` Vladimir Murzin 2016-04-26 9:10 ` Arnd Bergmann 2016-04-26 10:57 ` Vladimir Murzin 2016-04-26 11:59 ` Arnd Bergmann 2016-04-26 12:24 ` Vladimir Murzin 2016-04-26 18:12 ` Arnd Bergmann 2016-04-27 9:10 ` Vladimir Murzin 2016-04-27 9:50 ` Arnd Bergmann 2016-04-27 10:55 ` Vladimir Murzin 2016-04-27 11:18 ` Arnd Bergmann 2016-04-26 15:23 ` Afzal Mohammed 2016-04-28 9:41 ` Maxime Coquelin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.