| Message ID | 20161211131255.3221-1-afzal.mohd.ma@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Sun, Dec 11, 2016 at 06:42:55PM +0530, Afzal Mohammed wrote: > Kernel text start at an offset of at least 32K to account for page > tables in MMU case. Proper way to put it might have been "32K (to account for 16K initial page tables & the old atags)", unless i missed something. Regards afzal
On 11/12/16 13:12, Afzal Mohammed wrote: > Remap exception base address to start of RAM in Kernel in !MMU mode. > > Based on existing Kconfig help, Kernel was expecting it to be > configured by external support. Also earlier it was not possible to > copy the exception table to start of RAM due to Kconfig dependency, > which has been fixed by a change prior to this. > > Kernel text start at an offset of at least 32K to account for page > tables in MMU case. On a !MMU build too this space is kept aside, and > since 2 pages (8K) is the maximum for exception plus stubs, it can be > placed at the start of RAM. > > Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com> > --- > > i am a bit shaky about this change, though it works here on Cortex-A9, > this probably would have to be made robust so as to not cause issue on > other v7-A's upon trying to do !MMU (this won't affect normal MMU boot), > or specifically where security extensions are not enabled. Also effect > of hypervisor extension also need to be considered. Please let know if > any better ways to handle this. You might need to check ID_PFR1 for that. > > > arch/arm/Kconfig-nommu | 6 +++--- > arch/arm/kernel/head-nommu.S | 6 ++++++ > 2 files changed, 9 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu > index b7576349528c..f57fbe3d5eb0 100644 > --- a/arch/arm/Kconfig-nommu > +++ b/arch/arm/Kconfig-nommu > @@ -46,9 +46,9 @@ config REMAP_VECTORS_TO_RAM > If your CPU provides a remap facility which allows the exception > vectors to be mapped to writable memory, say 'n' here. > > - Otherwise, say 'y' here. In this case, the kernel will require > - external support to redirect the hardware exception vectors to > - the writable versions located at DRAM_BASE. > + Otherwise, say 'y' here. In this case, the kernel will > + redirect the hardware exception vectors to the writable > + versions located at DRAM_BASE. > > config ARM_MPU > bool 'Use the ARM v7 PMSA Compliant MPU' > diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S > index 6b4eb27b8758..ac31c9647830 100644 > --- a/arch/arm/kernel/head-nommu.S > +++ b/arch/arm/kernel/head-nommu.S > @@ -158,6 +158,12 @@ __after_proc_init: > bic r0, r0, #CR_V > #endif > mcr p15, 0, r0, c1, c0, 0 @ write control reg > + > +#ifdef CONFIG_REMAP_VECTORS_TO_RAM > + mov r3, #CONFIG_VECTORS_BASE @ read VECTORS_BASE ldr r3,=CONFIG_VECTORS_BASE would be more robust. I hit this in [1] [1] https://www.spinics.net/lists/arm-kernel/msg546825.html Cheers Vladimir > + mcr p15, 0, r3, c12, c0, 0 @ write to VBAR > +#endif > + > #elif defined (CONFIG_CPU_V7M) > /* For V7M systems we want to modify the CCR similarly to the SCTLR */ > #ifdef CONFIG_CPU_DCACHE_DISABLE >
On Sun, Dec 11, 2016 at 06:42:55PM +0530, Afzal Mohammed wrote: > Remap exception base address to start of RAM in Kernel in !MMU mode. > > Based on existing Kconfig help, Kernel was expecting it to be > configured by external support. Also earlier it was not possible to > copy the exception table to start of RAM due to Kconfig dependency, > which has been fixed by a change prior to this. > > Kernel text start at an offset of at least 32K to account for page > tables in MMU case. On a !MMU build too this space is kept aside, and > since 2 pages (8K) is the maximum for exception plus stubs, it can be > placed at the start of RAM. > > Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com> > --- > > i am a bit shaky about this change, though it works here on Cortex-A9, > this probably would have to be made robust so as to not cause issue on > other v7-A's upon trying to do !MMU (this won't affect normal MMU boot), > or specifically where security extensions are not enabled. Also effect > of hypervisor extension also need to be considered. Please let know if > any better ways to handle this. > > > arch/arm/Kconfig-nommu | 6 +++--- > arch/arm/kernel/head-nommu.S | 6 ++++++ > 2 files changed, 9 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu > index b7576349528c..f57fbe3d5eb0 100644 > --- a/arch/arm/Kconfig-nommu > +++ b/arch/arm/Kconfig-nommu > @@ -46,9 +46,9 @@ config REMAP_VECTORS_TO_RAM > If your CPU provides a remap facility which allows the exception > vectors to be mapped to writable memory, say 'n' here. > > - Otherwise, say 'y' here. In this case, the kernel will require > - external support to redirect the hardware exception vectors to > - the writable versions located at DRAM_BASE. > + Otherwise, say 'y' here. In this case, the kernel will > + redirect the hardware exception vectors to the writable > + versions located at DRAM_BASE. > > config ARM_MPU > bool 'Use the ARM v7 PMSA Compliant MPU' > diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S > index 6b4eb27b8758..ac31c9647830 100644 > --- a/arch/arm/kernel/head-nommu.S > +++ b/arch/arm/kernel/head-nommu.S > @@ -158,6 +158,12 @@ __after_proc_init: > bic r0, r0, #CR_V > #endif > mcr p15, 0, r0, c1, c0, 0 @ write control reg > + > +#ifdef CONFIG_REMAP_VECTORS_TO_RAM > + mov r3, #CONFIG_VECTORS_BASE @ read VECTORS_BASE > + mcr p15, 0, r3, c12, c0, 0 @ write to VBAR > +#endif > + Is there really any need to do this in head.S ? I believe it's entirely possible to do it later - arch/arm/mm/nommu.c:paging_init(). 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. That leaves one pr_notice() call using the CONFIG_VECTORS_BASE constant...
Hi, On Tue, Dec 13, 2016 at 10:02:26AM +0000, Russell King - ARM Linux wrote: > On Sun, Dec 11, 2016 at 06:42:55PM +0530, Afzal Mohammed wrote: > > bic r0, r0, #CR_V > > #endif > > mcr p15, 0, r0, c1, c0, 0 @ write control reg > > + > > +#ifdef CONFIG_REMAP_VECTORS_TO_RAM > > + mov r3, #CONFIG_VECTORS_BASE @ read VECTORS_BASE > > + mcr p15, 0, r3, c12, c0, 0 @ write to VBAR > > +#endif > > + > Is there really any need to do this in head.S ? Seeing the high vector configuration done here, pounced upon it :) > I believe it's > entirely possible to do it later - arch/arm/mm/nommu.c:paging_init(). > > 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. i will look into it. Regards afzal
Hi, On Tue, Dec 13, 2016 at 09:38:21AM +0000, Vladimir Murzin wrote: > On 11/12/16 13:12, Afzal Mohammed wrote: > > this probably would have to be made robust so as to not cause issue on > > other v7-A's upon trying to do !MMU (this won't affect normal MMU boot), > > or specifically where security extensions are not enabled. Also effect > > of hypervisor extension also need to be considered. Please let know if > > any better ways to handle this. > You might need to check ID_PFR1 for that. Had been searching ARM ARM for this kind of a thing, thanks. > > +#ifdef CONFIG_REMAP_VECTORS_TO_RAM > > + mov r3, #CONFIG_VECTORS_BASE @ read VECTORS_BASE > ldr r3,=CONFIG_VECTORS_BASE > > would be more robust. I hit this in [1] > > [1] https://www.spinics.net/lists/arm-kernel/msg546825.html Russell suggested doing it in paging_init(), then probably assembly circus can be avoided. Regards afzal
Hi, On Tue, Dec 13, 2016 at 10:02:26AM +0000, Russell King - ARM Linux wrote: > Is there really any need to do this in head.S ? I believe it's > entirely possible to do it later - arch/arm/mm/nommu.c:paging_init(). As memblock_reserve() for exception address was done before paging_init(), seems it has to be done by arm_mm_memblock_reserve() in arch/arm/mm/nommu.c, WIP patch follows, but not that happy - conditional compilation's make it not so readable, still better to see in C. > 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. Seems translating __setup_mpu() altogether to C & installing at a later, but suitable place might be better. And feeling something strange about Cortex-R support in mainline, don't know whether it boots out of the box, there are no Cortex-R cpu compatibles in dts(i), but devicetree documentation documents it. Still wrecking Cortex-R's could get counted as a regression as dts is not considered Kernel. Looks like there is a Cortex-R mafia around mainline ;) > That leaves one pr_notice() call using the CONFIG_VECTORS_BASE > constant... Seems you want to completely kick out CONFIG_VECTORS_BASE. Saw 2 interesting MMU cases, 1. in devicemaps_init(), if Hivecs is not set, it is being mapped to virtual address zero, was wondering how MMU Kernel can handle exceptions with zero address base (& still prints 0xffff0000 as vector base) 2. One of the platform does a ioremap of CONFIG_VECTORS_BASE Once i take care of the above, the ugly conditional compilation in 3/4th patch (@arch/arm/mm/init.c) of WIP patch series that follows will be removed. Please let know if you have any comments on the above. 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) with same Kernel image*. Vybrid did not need any platform specific tweaks, just 1/2th patch (put in patch system as 8635/1) & WIP series over Vladimir's one, while TI Sitara AMx3's needed one w.r.t remap. Please bear my delay - to fill the stomach, work not on Linux and then the vacations. Regards afzal * Since initramfs was used, tty port had to be changed in initramfs build for Vybrid, but Kernel except for above initramfs change, was identical.
diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu index b7576349528c..f57fbe3d5eb0 100644 --- a/arch/arm/Kconfig-nommu +++ b/arch/arm/Kconfig-nommu @@ -46,9 +46,9 @@ config REMAP_VECTORS_TO_RAM If your CPU provides a remap facility which allows the exception vectors to be mapped to writable memory, say 'n' here. - Otherwise, say 'y' here. In this case, the kernel will require - external support to redirect the hardware exception vectors to - the writable versions located at DRAM_BASE. + Otherwise, say 'y' here. In this case, the kernel will + redirect the hardware exception vectors to the writable + versions located at DRAM_BASE. config ARM_MPU bool 'Use the ARM v7 PMSA Compliant MPU' diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S index 6b4eb27b8758..ac31c9647830 100644 --- a/arch/arm/kernel/head-nommu.S +++ b/arch/arm/kernel/head-nommu.S @@ -158,6 +158,12 @@ __after_proc_init: bic r0, r0, #CR_V #endif mcr p15, 0, r0, c1, c0, 0 @ write control reg + +#ifdef CONFIG_REMAP_VECTORS_TO_RAM + mov r3, #CONFIG_VECTORS_BASE @ read VECTORS_BASE + mcr p15, 0, r3, c12, c0, 0 @ write to VBAR +#endif + #elif defined (CONFIG_CPU_V7M) /* For V7M systems we want to modify the CCR similarly to the SCTLR */ #ifdef CONFIG_CPU_DCACHE_DISABLE
Remap exception base address to start of RAM in Kernel in !MMU mode. Based on existing Kconfig help, Kernel was expecting it to be configured by external support. Also earlier it was not possible to copy the exception table to start of RAM due to Kconfig dependency, which has been fixed by a change prior to this. Kernel text start at an offset of at least 32K to account for page tables in MMU case. On a !MMU build too this space is kept aside, and since 2 pages (8K) is the maximum for exception plus stubs, it can be placed at the start of RAM. Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com> --- i am a bit shaky about this change, though it works here on Cortex-A9, this probably would have to be made robust so as to not cause issue on other v7-A's upon trying to do !MMU (this won't affect normal MMU boot), or specifically where security extensions are not enabled. Also effect of hypervisor extension also need to be considered. Please let know if any better ways to handle this. arch/arm/Kconfig-nommu | 6 +++--- arch/arm/kernel/head-nommu.S | 6 ++++++ 2 files changed, 9 insertions(+), 3 deletions(-)