From: Afzal Mohammed <afzal.mohd.ma@gmail.com> To: Russell King - ARM Linux <linux@armlinux.org.uk>, Vladimir Murzin <vladimir.murzin@arm.com> Cc: Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM Date: Sun, 15 Jan 2017 17:17:50 +0530 [thread overview] Message-ID: <20170115114750.GA5456@afzalpc> (raw) In-Reply-To: <20170107171339.GA5044@afzalpc> Hi, On Sat, Jan 07, 2017 at 10:43:39PM +0530, Afzal Mohammed wrote: > On Tue, Dec 13, 2016 at 10:02:26AM +0000, Russell King - ARM Linux wrote: > > Also, if the region setup for the vectors was moved as well, it would > > then be possible to check the ID registers to determine whether this > > is supported, and make the decision where to locate the vectors base > > more dynamically. > > This would affect Cortex-R's, which is a bit concerning due to lack of > those platforms with me, let me try to get it right. QEMU too doesn't seem to provide a Cortex-R target > Seems translating __setup_mpu() altogether to C afaics, a kind of C translation is already present as mpu_setup_region() in arch/arm/mm/nommu.c that takes care of MPU_RAM_REGION only. And that seems to be a kind of redundant as it is also done in asm at __setup_mpu(). Git blames asm & C to consecutive commits, that makes me a little shaky about the conclusion on it being redundant. > & installing at a later, but suitable place might be better. But looks like enabling MPU can't be moved to C & that would necessitate keeping at least some portion of__setu_mpu() in asm. Instead, moving region setup only for vectors to C as Russell suggested at first would have to be done. A kind of diff at the end is in my mind, with additional changes to handle the similar during secondary cpu bringup too. Thinking of invoking mpu_setup() from secondary_start_kernel() in arch/arm/kernel/smp.c, with mpu_setup() being slightly modified to avoid storing region details again when invoked by secondary cpu's. Vladimir, once changes are done after a revisit, i would need your help to test on Cortex-R. As an aside, wasn't aware of the fact that Cortex-R supports SMP Linux, had thought that, of !MMU one's, only Blackfin & J2 had it. > Also !MMU Kernel could boot on 3 ARM v7-A platforms - AM335x Beagle > Bone (A8), AM437x IDK (A9) & Vybrid VF610 (on A5 core, note that it > has M4 core too) Talking about Cortex-M, AMx3's too have it, to be specific M3, but they are not Linux-able unlike the one in VF610. Regards afzal --->8--- diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S index e0565d73e49e..f8ac79b6136d 100644 --- a/arch/arm/kernel/head-nommu.S +++ b/arch/arm/kernel/head-nommu.S @@ -249,20 +249,6 @@ ENTRY(__setup_mpu) setup_region r0, r5, r6, MPU_INSTR_SIDE @ 0x0, BG region, enabled 2: isb - /* Vectors region */ - set_region_nr r0, #MPU_VECTORS_REGION - isb - /* Shared, inaccessible to PL0, rw PL1 */ - 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, #(((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 - setup_region r0, r5, r6, MPU_INSTR_SIDE @ VECTORS_BASE, PL0 NA, enabled -3: isb - /* Enable the MPU */ mrc p15, 0, r0, c1, c0, 0 @ Read SCTLR bic r0, r0, #CR_BR @ Disable the 'default mem-map' diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c index e82056df0635..7fe8906322d5 100644 --- a/arch/arm/mm/nommu.c +++ b/arch/arm/mm/nommu.c @@ -269,12 +269,19 @@ void __init mpu_setup(void) ilog2(memblock.memory.regions[0].size), MPU_AP_PL1RW_PL0RW | MPU_RGN_NORMAL); if (region_err) { - panic("MPU region initialization failure! %d", region_err); + panic("MPU RAM region initialization failure! %d", region_err); } else { - pr_info("Using ARMv7 PMSA Compliant MPU. " - "Region independence: %s, Max regions: %d\n", - mpu_iside_independent() ? "Yes" : "No", - mpu_max_regions()); + region_err = mpu_setup_region(MPU_VECTORS_REGION, vectors_base, + ilog2(memblock.memory.regions[0].size), + MPU_AP_PL1RW_PL0NA | MPU_RGN_NORMAL); + if (region_err) { + panic("MPU VECTOR region initialization failure! %d", + region_err); + } else { + pr_info("Using ARMv7 PMSA Compliant MPU. " + "Region independence: %s, Max regions: %d\n", + mpu_iside_independent() ? "Yes" : "No", + mpu_max_regions()); } } #else
WARNING: multiple messages have this Message-ID (diff)
From: afzal.mohd.ma@gmail.com (Afzal Mohammed) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM Date: Sun, 15 Jan 2017 17:17:50 +0530 [thread overview] Message-ID: <20170115114750.GA5456@afzalpc> (raw) In-Reply-To: <20170107171339.GA5044@afzalpc> Hi, On Sat, Jan 07, 2017 at 10:43:39PM +0530, Afzal Mohammed wrote: > On Tue, Dec 13, 2016 at 10:02:26AM +0000, Russell King - ARM Linux wrote: > > Also, if the region setup for the vectors was moved as well, it would > > then be possible to check the ID registers to determine whether this > > is supported, and make the decision where to locate the vectors base > > more dynamically. > > This would affect Cortex-R's, which is a bit concerning due to lack of > those platforms with me, let me try to get it right. QEMU too doesn't seem to provide a Cortex-R target > Seems translating __setup_mpu() altogether to C afaics, a kind of C translation is already present as mpu_setup_region() in arch/arm/mm/nommu.c that takes care of MPU_RAM_REGION only. And that seems to be a kind of redundant as it is also done in asm at __setup_mpu(). Git blames asm & C to consecutive commits, that makes me a little shaky about the conclusion on it being redundant. > & installing at a later, but suitable place might be better. But looks like enabling MPU can't be moved to C & that would necessitate keeping at least some portion of__setu_mpu() in asm. Instead, moving region setup only for vectors to C as Russell suggested at first would have to be done. A kind of diff at the end is in my mind, with additional changes to handle the similar during secondary cpu bringup too. Thinking of invoking mpu_setup() from secondary_start_kernel() in arch/arm/kernel/smp.c, with mpu_setup() being slightly modified to avoid storing region details again when invoked by secondary cpu's. Vladimir, once changes are done after a revisit, i would need your help to test on Cortex-R. As an aside, wasn't aware of the fact that Cortex-R supports SMP Linux, had thought that, of !MMU one's, only Blackfin & J2 had it. > Also !MMU Kernel could boot on 3 ARM v7-A platforms - AM335x Beagle > Bone (A8), AM437x IDK (A9) & Vybrid VF610 (on A5 core, note that it > has M4 core too) Talking about Cortex-M, AMx3's too have it, to be specific M3, but they are not Linux-able unlike the one in VF610. Regards afzal --->8--- diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S index e0565d73e49e..f8ac79b6136d 100644 --- a/arch/arm/kernel/head-nommu.S +++ b/arch/arm/kernel/head-nommu.S @@ -249,20 +249,6 @@ ENTRY(__setup_mpu) setup_region r0, r5, r6, MPU_INSTR_SIDE @ 0x0, BG region, enabled 2: isb - /* Vectors region */ - set_region_nr r0, #MPU_VECTORS_REGION - isb - /* Shared, inaccessible to PL0, rw PL1 */ - 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, #(((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 - setup_region r0, r5, r6, MPU_INSTR_SIDE @ VECTORS_BASE, PL0 NA, enabled -3: isb - /* Enable the MPU */ mrc p15, 0, r0, c1, c0, 0 @ Read SCTLR bic r0, r0, #CR_BR @ Disable the 'default mem-map' diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c index e82056df0635..7fe8906322d5 100644 --- a/arch/arm/mm/nommu.c +++ b/arch/arm/mm/nommu.c @@ -269,12 +269,19 @@ void __init mpu_setup(void) ilog2(memblock.memory.regions[0].size), MPU_AP_PL1RW_PL0RW | MPU_RGN_NORMAL); if (region_err) { - panic("MPU region initialization failure! %d", region_err); + panic("MPU RAM region initialization failure! %d", region_err); } else { - pr_info("Using ARMv7 PMSA Compliant MPU. " - "Region independence: %s, Max regions: %d\n", - mpu_iside_independent() ? "Yes" : "No", - mpu_max_regions()); + region_err = mpu_setup_region(MPU_VECTORS_REGION, vectors_base, + ilog2(memblock.memory.regions[0].size), + MPU_AP_PL1RW_PL0NA | MPU_RGN_NORMAL); + if (region_err) { + panic("MPU VECTOR region initialization failure! %d", + region_err); + } else { + pr_info("Using ARMv7 PMSA Compliant MPU. " + "Region independence: %s, Max regions: %d\n", + mpu_iside_independent() ? "Yes" : "No", + mpu_max_regions()); } } #else
next prev parent reply other threads:[~2017-01-15 11:48 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-12-11 13:10 [PATCH 0/2] ARM: v7-A !MMU fixes for fun (&fame) Afzal Mohammed 2016-12-11 13:10 ` Afzal Mohammed 2016-12-11 13:11 ` [PATCH 1/2] ARM: nommu: allow enabling REMAP_VECTORS_TO_RAM Afzal Mohammed 2016-12-11 13:11 ` Afzal Mohammed 2016-12-13 9:17 ` Vladimir Murzin 2016-12-13 9:17 ` Vladimir Murzin 2016-12-11 13:12 ` [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM Afzal Mohammed 2016-12-11 13:12 ` Afzal Mohammed 2016-12-11 14:42 ` Afzal Mohammed 2016-12-11 14:42 ` Afzal Mohammed 2016-12-13 9:38 ` Vladimir Murzin 2016-12-13 9:38 ` Vladimir Murzin 2016-12-13 18:44 ` Afzal Mohammed 2016-12-13 18:44 ` Afzal Mohammed 2016-12-13 10:02 ` Russell King - ARM Linux 2016-12-13 10:02 ` Russell King - ARM Linux 2016-12-13 18:35 ` Afzal Mohammed 2016-12-13 18:35 ` Afzal Mohammed 2017-01-07 17:13 ` Afzal Mohammed 2017-01-07 17:13 ` Afzal Mohammed 2017-01-07 17:20 ` [PATCH WIP 1/4] ARM: nommu: dynamic exception base address setting afzal mohammed 2017-01-07 17:20 ` afzal mohammed 2017-01-07 17:21 ` [PATCH WIP 2/4] ARM: nommu: remove Hivecs configuration is asm afzal mohammed 2017-01-07 17:21 ` afzal mohammed 2017-01-07 17:22 ` [PATCH WIP 3/4] ARM: mm: nommu: display dynamic exception base afzal mohammed 2017-01-07 17:22 ` afzal mohammed 2017-01-07 17:22 ` [PATCH WIP 4/4] ARM: remove compile time vector base for CP15 case afzal mohammed 2017-01-07 17:22 ` afzal mohammed 2017-01-07 17:38 ` Russell King - ARM Linux 2017-01-07 17:38 ` Russell King - ARM Linux 2017-01-07 18:02 ` Afzal Mohammed 2017-01-07 18:02 ` Afzal Mohammed 2017-01-07 18:07 ` Afzal Mohammed 2017-01-07 18:07 ` Afzal Mohammed 2017-01-07 18:24 ` Russell King - ARM Linux 2017-01-07 18:24 ` Russell King - ARM Linux 2017-01-08 9:58 ` Afzal Mohammed 2017-01-08 9:58 ` Afzal Mohammed 2017-01-15 11:47 ` Afzal Mohammed [this message] 2017-01-15 11:47 ` [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM Afzal Mohammed 2017-01-16 9:53 ` Vladimir Murzin 2017-01-16 9:53 ` Vladimir Murzin 2017-01-16 12:34 ` Afzal Mohammed 2017-01-16 12:34 ` Afzal Mohammed 2016-12-12 18:44 ` [PATCH 0/2] ARM: v7-A !MMU fixes for fun (&fame) Afzal Mohammed 2016-12-12 18:44 ` Afzal Mohammed 2016-12-12 20:42 ` Peter Korsgaard 2016-12-12 20:42 ` Peter Korsgaard
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170115114750.GA5456@afzalpc \ --to=afzal.mohd.ma@gmail.com \ --cc=arnd@arndb.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=vladimir.murzin@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.