[PATCH 0/2] ARM: v7-A !MMU fixes for fun (&fame)

[PATCH 0/2] ARM: v7-A !MMU fixes for fun (&fame)

[Afzal Mohammed]

Hi,

ARM core fixes required to bring up !MMU Kernel on v7 Cortex-A.

This was done on top of Vladimir Murzin's !MMU multiplatform series[1].

Platform used was Cortex-A9, AM437x IDK.

Kernel reached the stage of invoking user space init & panicked, though
it could not reach till prompt for want of user space executables, it
went as much as Kernel can help by itself. But that is an issue
independent of the Kernel, hence posting the series (also thought of
at least posting the existing patches b'fore merge window starts).

So far i have not come across a toolchain (or a way to create toolchain)
to create !MMU user space executables for Cortex-A. It is being hoped
that Cortex-R toolchain might help here (Thanks Arnd). This is being
looked into.

multi_v7_defconfig was used & all platforms except TI OMAP/AM/DM/DRA &
Freescale i.MX family was deselected. ARM_MPU option was disabled as
Vladimir had given an early warning. DRAM_BASE was set to 0x80000000.
During the course of bringup, futex was causing issues, hence FUTEX was
removed. L1 & L2 caches were disabled in config. High vectors were
disabled & vectors were made to remap to base of RAM. An additional OMAP
specific change to avoid one ioremap was also required.

2/2th patch has been sticked with RFC label, as, though it works, it
might 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.

Boot logs at the end.


Afzal Mohammed (2):
  ARM: nommu: allow enabling REMAP_VECTORS_TO_RAM
  ARM: nommu: remap exception base address to RAM

 arch/arm/Kconfig-nommu       | 9 ++++-----
 arch/arm/kernel/head-nommu.S | 6 ++++++
 2 files changed, 10 insertions(+), 5 deletions(-)

[1] "[RFC v2 PATCH 00/23] Allow NOMMU for MULTIPLATFORM",
    http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470966.html
    (git://linux-arm.org/linux-vm.git nommu-rfc-v2)

[2] Boot log

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.0-rc7-00026-g7a142ca8231b (afzal@debian) (gcc version 6.2.0 (GCC) ) #23 Sun Dec 11 14:59:57 IST 2016
[    0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=00c50478
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt:Machine model: TI AM437x Industrial Development Kit
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] AM437x ES1.2 (sgx neon)
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
[    0.000000] Kernel command line: console=ttyO0,115200n8 root=/dev/ram0 rw initrd=0x81800000,8M earlyprintk
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 1021276K/1048576K available (6558K kernel code, 523K rwdata, 2096K rodata, 444K init, 274K bss, 27300K reserved, 0K cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0x80000000 - 0x80001000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0x00000000 - 0xffffffff   (4095 MB)
[    0.000000]     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
[    0.000000]     modules : 0x80000000 - 0xc0000000   (1024 MB)
[    0.000000]       .text : 0x80008000 - 0x8066f948   (6559 kB)
[    0.000000]       .init : 0x8087d000 - 0x808ec000   ( 444 kB)
[    0.000000]       .data : 0x808ec000 - 0x8096ef60   ( 524 kB)
[    0.000000]        .bss : 0x8096ef60 - 0x809b3a9c   ( 275 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] OMAP clockevent source: timer1 at 32786 Hz
[    0.000255] sched_clock: 64 bits at 500MHz, resolution 2ns, wraps every 4398046511103ns
[    0.009514] clocksource: arm_global_timer: mask: 0xffffffffffffffff max_cycles: 0xe6a171a037, max_idle_ns: 881590485102 ns
[    0.021986] Switching to timer-based delay loop, resolution 2ns
[    0.140838] clocksource: 32k_counter: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
[    0.151820] OMAP clocksource: 32k_counter at 32768 Hz
[    0.230698] Console: colour dummy device 80x30
[    0.236205] Calibrating delay loop (skipped), value calculated using timer frequency.. 1000.00 BogoMIPS (lpj=5000000)
[    0.248268] pid_max: default: 32768 minimum: 301
[    0.255822] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.263618] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.322900] devtmpfs: initialized
[    0.936367] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[    0.952252] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.964401] pinctrl core: initialized pinctrl subsystem
[    1.014271] NET: Registered protocol family 16
[    2.116314] cpuidle: using governor menu
[    2.185476] omap_l3_noc 44000000.ocp: L3 debug error: target 8 mod:0 (unclearable)
[    2.195318] omap_l3_noc 44000000.ocp: L3 application error: target 8 mod:0 (unclearable)
[    2.498901] OMAP GPIO hardware version 0.1
[    2.880457] platform 53701000.des: Cannot lookup hwmod 'des'
[    2.897229] platform 48310000.rng: Cannot lookup hwmod 'rng'
[    3.042436] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[    3.051608] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    3.067955] omap4_sram_init:Unable to allocate sram needed to handle errata I688
[    3.076481] omap4_sram_init:Unable to get sram pool needed to handle errata I688
[    4.002793] edma 49000000.edma: TI EDMA DMA engine driver
[    4.028172] V3_3D: supplied by V24_0D
[    4.042678] VDD_COREREG: supplied by V24_0D
[    4.058179] VDD_CORE: supplied by VDD_COREREG
[    4.073926] V1_8DREG: supplied by V24_0D
[    4.089154] V1_8D: supplied by V1_8DREG
[    4.104080] V1_5DREG: supplied by V24_0D
[    4.119127] V1_5D: supplied by V1_5DREG
[    4.273112] vgaarb: loaded
[    4.310009] SCSI subsystem initialized
[    4.328627] usbcore: registered new interface driver usbfs
[    4.337597] usbcore: registered new interface driver hub
[    4.345367] usbcore: registered new device driver usb
[    4.366408] omap_i2c 44e0b000.i2c: could not find pctldev for node /ocp@44000000/l4_wkup@44c00000/scm@210000/pinmux@800/i2c0_pins_default, deferring probe
[    4.382947] omap_i2c 4819c000.i2c: could not find pctldev for node /ocp@44000000/l4_wkup@44c00000/scm@210000/pinmux@800/i2c2_pins_default, deferring probe
[    4.403752] pps_core: LinuxPPS API ver. 1 registered
[    4.409476] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    4.420441] PTP clock support registered
[    4.432462] EDAC MC: Ver: 3.0.0
[    4.493322] clocksource: Switched to clocksource arm_global_timer
[    4.869692] NET: Registered protocol family 2
[    4.898940] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    4.912636] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[    4.925797] TCP: Hash tables configured (established 8192 bind 8192)
[    4.935378] UDP hash table entries: 512 (order: 1, 8192 bytes)
[    4.943318] UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
[    4.954721] NET: Registered protocol family 1
[    4.966327] RPC: Registered named UNIX socket transport module.
[    4.973033] RPC: Registered udp transport module.
[    4.978697] RPC: Registered tcp transport module.
[    4.984370] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    5.001882] Trying to unpack rootfs image as initramfs...
[    5.034070] rootfs image is not initramfs (no cpio magic); looks like an initrd
[    6.359174] Freeing initrd memory: 8192K (81800000 - 82000000)
[    6.453302] workingset: timestamp_bits=30 max_order=18 bucket_order=0
[    6.910863] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    6.964046] NFS: Registering the id_resolver key type
[    6.970315] Key type id_resolver registered
[    6.975420] Key type id_legacy registered
[    6.981225] ntfs: driver 2.1.32 [Flags: R/O].
[    7.037313] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
[    7.045863] io scheduler noop registered
[    7.050452] io scheduler deadline registered
[    7.065425] io scheduler cfq registered (default)
[    7.161373] pinctrl-single 44e10800.pinmux: 199 pins at pa 44e10800 size 796
[    9.535089] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    9.644270] omap_uart 44e09000.serial: no wakeirq for uart0
[    9.650936] omap_uart 44e09000.serial: No clock speed specified: using default: 48000000
[    9.662676] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 29, base_baud = 3000000) is a OMAP UART0
[    9.673897] console [ttyO0] enabled
[    9.673897] console [ttyO0] enabled
[    9.682034] bootconsole [earlycon0] disabled
[    9.682034] bootconsole [earlycon0] disabled
[    9.708232] STMicroelectronics ASC driver initialized
[    9.754052] omap_rng 48310000.rng: _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info
[    9.764695] omap_rng 48310000.rng: Failed to runtime_get device: -19
[    9.772443] omap_rng 48310000.rng: initialization failed.
[   10.195514] brd: module loaded
[   10.422154] loop: module loaded
[   10.591936] libphy: Fixed MDIO Bus: probed
[   10.662542] CAN device driver interface
[   10.737391] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[   10.744646] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[   10.754902] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
[   10.763205] igb: Copyright (c) 2007-2014 Intel Corporation.
[   10.973943] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[   10.981436] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
[   10.999526] libphy: 4a101000.mdio: probed
[   11.004917] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver Micrel KSZ9031 Gigabit PHY
[   11.038793] cpsw 4a100000.ethernet: Detected MACID = c4:be:84:cc:f8:b2
[   11.095184] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver
[   11.106034] usbcore: registered new interface driver pegasus
[   11.115479] usbcore: registered new interface driver asix
[   11.124060] usbcore: registered new interface driver ax88179_178a
[   11.133203] usbcore: registered new interface driver cdc_ether
[   11.142987] usbcore: registered new interface driver smsc75xx
[   11.152860] usbcore: registered new interface driver smsc95xx
[   11.161841] usbcore: registered new interface driver net1080
[   11.170867] usbcore: registered new interface driver cdc_subset
[   11.180063] usbcore: registered new interface driver zaurus
[   11.189712] usbcore: registered new interface driver cdc_ncm
[   11.260711] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[   11.268771] ehci-pci: EHCI PCI platform driver
[   11.276303] ehci-platform: EHCI generic platform driver
[   11.292469] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[   11.300232] ohci-pci: OHCI PCI platform driver
[   11.307765] ohci-platform: OHCI generic platform driver
[   11.320423] ohci-omap3: OHCI OMAP3 driver
[   11.361822] usbcore: registered new interface driver usb-storage
[   11.436768] mousedev: PS/2 mouse device common for all mice
[   11.483706] i2c /dev entries driver
[   11.651196] sdhci: Secure Digital Host Controller Interface driver
[   11.658834] sdhci: Copyright(c) Pierre Ossman
[   11.682975] omap_hsmmc 48060000.mmc: Got CD GPIO
[   11.760972] Synopsys Designware Multimedia Card Interface Driver
[   11.790084] sdhci-pltfm: SDHCI platform and OF driver helper
[   11.838871] ledtrig-cpu: registered to indicate activity on CPUs
[   11.853073] usbcore: registered new interface driver usbhid
[   11.860012] usbhid: USB HID core driver
[   11.907366] NET: Registered protocol family 10
[   11.958684] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[   11.995847] NET: Registered protocol family 17
[   12.001416] can: controller area network core (rev 20120528 abi 9)
[   12.011131] NET: Registered protocol family 29
[   12.016810] can: raw protocol (rev 20120528)
[   12.022021] can: broadcast manager protocol (rev 20161123 t)
[   12.029239] can: netlink gateway (rev 20130117) max_hops=1
[   12.050005] Key type dns_resolver registered
[   12.064564] omap_voltage_late_init: Voltage driver support not added
[   12.077074] ThumbEE CPU extension supported.
[   12.308431] mmc0: host does not support reading read-only switch, assuming write-enable
[   12.321471] mmc0: new high speed SDHC card at address 0002
[   12.345989] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 64 bytes/write
[   12.368663] mmcblk0: mmc0:0002 00000 3.66 GiB 
[   12.394788] omap_i2c 44e0b000.i2c: bus 0 rev0.12 at 400 kHz
[   12.421561]  mmcblk0: p1 p2
[   12.461994] omap_i2c 4819c000.i2c: bus 2 rev0.12 at 100 kHz
[   12.492765] input: gpio_keys as /devices/platform/gpio_keys/input/input0
[   12.507921] hctosys: unable to open rtc device (rtc0)
[   12.538496] RAMDISK: gzip image found at block 0
[   15.374579] EXT4-fs (ram0): couldn't mount as ext3 due to feature incompatibilities
[   15.385965] EXT4-fs (ram0): mounting ext2 file system using the ext4 subsystem
[   15.424025] EXT4-fs (ram0): mounted filesystem without journal. Opts: (null)
[   15.432741] VFS: Mounted root (ext2 filesystem) on device 1:0.
[   15.441488] devtmpfs: mounted
[   15.480818] Freeing unused kernel memory: 444K (8087d000 - 808ec000)
[   15.488676] This architecture does not have kernel memory protection.
[   15.502853] Starting init: /sbin/init exists but couldn't execute it (error -8)
[   15.515466] Starting init: /bin/sh exists but couldn't execute it (error -8)
[   15.524269] Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
[   15.539836] CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc7-00026-g7a142ca8231b #23
[   15.549157] Hardware name: Generic AM43 (Flattened Device Tree)
[   15.556400] ---[ end Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.

-- 
2.11.0

[PATCH 1/2] ARM: nommu: allow enabling REMAP_VECTORS_TO_RAM

[Afzal Mohammed]

REMAP_VECTORS_TO_RAM depends on DRAM_BASE, but since DRAM_BASE is a
hex, REMAP_VECTORS_TO_RAM could never get enabled. Also depending on
DRAM_BASE is redundant as whenever REMAP_VECTORS_TO_RAM makes itself
available to Kconfig, DRAM_BASE also is available as the Kconfig gets
sourced on !MMU.

Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
---
 arch/arm/Kconfig-nommu | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu
index aed66d5df7f1..b7576349528c 100644
--- a/arch/arm/Kconfig-nommu
+++ b/arch/arm/Kconfig-nommu
@@ -34,8 +34,7 @@ config PROCESSOR_ID
 	  used instead of the auto-probing which utilizes the register.
 
 config REMAP_VECTORS_TO_RAM
-	bool 'Install vectors to the beginning of RAM' if DRAM_BASE
-	depends on DRAM_BASE
+	bool 'Install vectors to the beginning of RAM'
 	help
 	  The kernel needs to change the hardware exception vectors.
 	  In nommu mode, the hardware exception vectors are normally
-- 
2.11.0

[PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM

[Afzal Mohammed]

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
+
 #elif defined (CONFIG_CPU_V7M)
 	/* For V7M systems we want to modify the CCR similarly to the SCTLR */
 #ifdef CONFIG_CPU_DCACHE_DISABLE
-- 
2.11.0

Re: [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM

[Afzal Mohammed]

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

Re: [PATCH 0/2] ARM: v7-A !MMU fixes for fun (&fame)

[Afzal Mohammed]

Hi,

On Sun, Dec 11, 2016 at 06:40:28PM +0530, Afzal Mohammed wrote:

> Kernel reached the stage of invoking user space init & panicked, though
> it could not reach till prompt for want of user space executables
> 
> So far i have not come across a toolchain (or a way to create toolchain)
> to create !MMU user space executables for Cortex-A.

Now able to reach prompt using buildroot initramfs, Thanks to
Peter Korsgaard for suggesting the way to create user space executables
for !MMU Cortex-A.

> multi_v7_defconfig was used & all platforms except TI OMAP/AM/DM/DRA &
> Freescale i.MX family was deselected. ARM_MPU option was disabled as
> Vladimir had given an early warning. DRAM_BASE was set to 0x80000000.
> During the course of bringup, futex was causing issues, hence FUTEX was
> removed. L1 & L2 caches were disabled in config. High vectors were
> disabled & vectors were made to remap to base of RAM. An additional OMAP
> specific change to avoid one ioremap was also required.

For the sake of completeness,
SMP was disabled & flat binary support enabled in Kernel.

Regards
afzal

Re: [PATCH 0/2] ARM: v7-A !MMU fixes for fun (&fame)

[Peter Korsgaard]

>>>>> "Afzal" == Afzal Mohammed <afzal.mohd.ma@gmail.com> writes:

 > Hi,
 > On Sun, Dec 11, 2016 at 06:40:28PM +0530, Afzal Mohammed wrote:

 >> Kernel reached the stage of invoking user space init & panicked, though
 >> it could not reach till prompt for want of user space executables
 >> 
 >> So far i have not come across a toolchain (or a way to create toolchain)
 >> to create !MMU user space executables for Cortex-A.

 > Now able to reach prompt using buildroot initramfs, Thanks to
 > Peter Korsgaard for suggesting the way to create user space executables
 > for !MMU Cortex-A.

Great, thats nice to hear!

-- 
Bye, Peter Korsgaard

Re: [PATCH 1/2] ARM: nommu: allow enabling REMAP_VECTORS_TO_RAM

[Vladimir Murzin]

On 11/12/16 13:11, Afzal Mohammed wrote:
> REMAP_VECTORS_TO_RAM depends on DRAM_BASE, but since DRAM_BASE is a
> hex, REMAP_VECTORS_TO_RAM could never get enabled. Also depending on
> DRAM_BASE is redundant as whenever REMAP_VECTORS_TO_RAM makes itself
> available to Kconfig, DRAM_BASE also is available as the Kconfig gets
> sourced on !MMU.
> 
> Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
> ---
>  arch/arm/Kconfig-nommu | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu
> index aed66d5df7f1..b7576349528c 100644
> --- a/arch/arm/Kconfig-nommu
> +++ b/arch/arm/Kconfig-nommu
> @@ -34,8 +34,7 @@ config PROCESSOR_ID
>  	  used instead of the auto-probing which utilizes the register.
>  
>  config REMAP_VECTORS_TO_RAM
> -	bool 'Install vectors to the beginning of RAM' if DRAM_BASE
> -	depends on DRAM_BASE
> +	bool 'Install vectors to the beginning of RAM'
>  	help
>  	  The kernel needs to change the hardware exception vectors.
>  	  In nommu mode, the hardware exception vectors are normally
> 

I have similar change in my local tree, so FWIW:

Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>

Re: [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM

[Vladimir Murzin]

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
> 

Re: [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM

[Russell King - ARM Linux]

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...

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM

[Afzal Mohammed]

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

Re: [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM

[Afzal Mohammed]

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

Re: [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM

[Afzal Mohammed]

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.

[PATCH WIP 1/4] ARM: nommu: dynamic exception base address setting

[afzal mohammed]

No-MMU dynamic exception base address configuration on processors
with CP15.

TODO: Handle MMU case as well as ARM_MPU scenario dynamically

Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
---
 arch/arm/mm/nommu.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 60 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 681cec879caf..e82056df0635 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -11,6 +11,7 @@
 #include <linux/kernel.h>
 
 #include <asm/cacheflush.h>
+#include <asm/cp15.h>
 #include <asm/sections.h>
 #include <asm/page.h>
 #include <asm/setup.h>
@@ -23,6 +24,8 @@
 
 #include "mm.h"
 
+unsigned long vectors_base;
+
 #ifdef CONFIG_ARM_MPU
 struct mpu_rgn_info mpu_rgn_info;
 
@@ -279,15 +282,70 @@ static void sanity_check_meminfo_mpu(void) {}
 static void __init mpu_setup(void) {}
 #endif /* CONFIG_ARM_MPU */
 
+#ifdef CONFIG_CPU_CP15
+/*
+ * ID_PRF1 bits (CP#15 ID_PFR1)
+ */
+#define ID_PFR1_SE (0x3 << 4)	/* Security extension enable bits */
+
+#ifndef CONFIG_CPU_HIGH_VECTOR
+static inline unsigned long get_id_pfr1(void)
+{
+	unsigned long val;
+	asm("mrc p15, 0, %0, c0, c1, 1" : "=r" (val) : : "cc");
+	return val;
+}
+
+static inline void set_vbar(unsigned long val)
+{
+	asm("mcr p15, 0, %0, c12, c0, 0" : : "r" (val) : "cc");
+}
+
+static bool __init security_extensions_enabled(void)
+{
+	return !!(get_id_pfr1() & ID_PFR1_SE);
+}
+#endif
+
+static unsigned long __init setup_vector_base(void)
+{
+	unsigned long reg, base;
+
+	reg = get_cr();
+
+#ifdef CONFIG_CPU_HIGH_VECTOR
+	set_cr(reg | CR_V);
+	base = 0xFFFF0000;
+#else
+	set_cr(reg & ~CR_V);
+	base = 0;
+	if (security_extensions_enabled()) {
+#ifdef CONFIG_REMAP_VECTORS_TO_RAM
+		base = CONFIG_DRAM_BASE;
+#endif
+		set_vbar(base);
+	}
+#endif /* CONFIG_CPU_HIGH_VECTOR */
+
+	return base;
+}
+#endif /* CONFIG_CPU_CP15 */
+
 void __init arm_mm_memblock_reserve(void)
 {
 #ifndef CONFIG_CPU_V7M
+
+#ifdef CONFIG_CPU_CP15
+	vectors_base = setup_vector_base();
+#else
+	vectors_base = CONFIG_VECTORS_BASE;
+#endif
 	/*
 	 * Register the exception vector page.
 	 * 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, 2 * PAGE_SIZE);
+	memblock_reserve(vectors_base, 2 * PAGE_SIZE);
 #else /* ifndef CONFIG_CPU_V7M */
 	/*
 	 * There is no dedicated vector page on V7-M. So nothing needs to be
@@ -311,7 +369,7 @@ void __init sanity_check_meminfo(void)
  */
 void __init paging_init(const struct machine_desc *mdesc)
 {
-	early_trap_init((void *)CONFIG_VECTORS_BASE);
+	early_trap_init((void *)vectors_base);
 	mpu_setup();
 	bootmem_init();
 }
-- 
2.11.0

[PATCH WIP 2/4] ARM: nommu: remove Hivecs configuration is asm

[afzal mohammed]

Now that exception based address is handled dynamically for
processors with CP15, remove Hivecs configuration in assembly.

Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
---
 arch/arm/kernel/head-nommu.S | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index 2ab026ffc270..e0565d73e49e 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -162,11 +162,6 @@ ENDPROC(secondary_startup_arm)
 #ifdef CONFIG_CPU_ICACHE_DISABLE
 	bic	r0, r0, #CR_I
 #endif
-#ifdef CONFIG_CPU_HIGH_VECTOR
-	orr	r0, r0, #CR_V
-#else
-	bic	r0, r0, #CR_V
-#endif
 	mcr	p15, 0, r0, c1, c0, 0		@ write control reg
 #elif defined (CONFIG_CPU_V7M)
 	/* For V7M systems we want to modify the CCR similarly to the SCTLR */
-- 
2.11.0

[PATCH WIP 3/4] ARM: mm: nommu: display dynamic exception base

[afzal mohammed]

Display dynamically estimated nommu exception base.

TODO: Dynamically update MMU case too.

Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
---
 arch/arm/mm/init.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 370581aeb871..1777ee23a6a2 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -39,6 +39,10 @@
 
 #include "mm.h"
 
+#ifndef CONFIG_MMU
+extern unsigned long vectors_base;
+#endif
+
 #ifdef CONFIG_CPU_CP15_MMU
 unsigned long __init __clear_cr(unsigned long mask)
 {
@@ -521,8 +525,13 @@ void __init mem_init(void)
 			"      .data : 0x%p" " - 0x%p" "   (%4td kB)\n"
 			"       .bss : 0x%p" " - 0x%p" "   (%4td kB)\n",
 
+#ifdef CONFIG_MMU
 			MLK(UL(CONFIG_VECTORS_BASE), UL(CONFIG_VECTORS_BASE) +
 				(PAGE_SIZE)),
+#else
+			MLK_ROUNDUP(vectors_base, vectors_base + PAGE_SIZE),
+#endif
+
 #ifdef CONFIG_HAVE_TCM
 			MLK(DTCM_OFFSET, (unsigned long) dtcm_end),
 			MLK(ITCM_OFFSET, (unsigned long) itcm_end),
-- 
2.11.0

[PATCH WIP 4/4] ARM: remove compile time vector base for CP15 case

[afzal mohammed]

vectors base is now dynamically updated for Hivecs as well as for
REMAP_VECTORS_TO_RAM case to DRAM_START. Hence remove these CP15
cases.

TODO:
Kill off VECTORS_BASE completely - this would require to handle MMU
 case as well as ARM_MPU scenario dynamically.

Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
---
 arch/arm/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index bc6f4065840e..720ee62b4955 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -232,8 +232,7 @@ config ARCH_MTD_XIP
 
 config VECTORS_BASE
 	hex
-	default 0xffff0000 if MMU || CPU_HIGH_VECTOR
-	default DRAM_BASE if REMAP_VECTORS_TO_RAM
+	default 0xffff0000 if MMU
 	default 0x00000000
 	help
 	  The base address of exception vectors.  This must be two pages
-- 
2.11.0

Re: [PATCH WIP 4/4] ARM: remove compile time vector base for CP15 case

[Russell King - ARM Linux]

On Sat, Jan 07, 2017 at 10:52:28PM +0530, afzal mohammed wrote:
> vectors base is now dynamically updated for Hivecs as well as for
> REMAP_VECTORS_TO_RAM case to DRAM_START. Hence remove these CP15
> cases.
> 
> TODO:
> Kill off VECTORS_BASE completely - this would require to handle MMU
>  case as well as ARM_MPU scenario dynamically.

Why do you think MMU doesn't already handle it?

>  config VECTORS_BASE
>  	hex
> -	default 0xffff0000 if MMU || CPU_HIGH_VECTOR
> -	default DRAM_BASE if REMAP_VECTORS_TO_RAM
> +	default 0xffff0000 if MMU
>  	default 0x00000000

When MMU=y, the resulting VECTORS_BASE is always 0xffff0000.  The only
case where this ends up zero after your change is when MMU=n.

In any case here's the places it's used:

For nommu:
arch/arm/kernel/head-nommu.S:       mov     r0, #CONFIG_VECTORS_BASE   @ Cover from VECTORS_BASE
arch/arm/kernel/head-nommu.S:       setup_region r0, r5, r6, MPU_DATA_SIDE  @ VECTORS_BASE, PL0 NA, enabled
arch/arm/kernel/head-nommu.S:       setup_region r0, r5, r6, MPU_INSTR_SIDE @ VECTORS_BASE, PL0 NA, enabled
arch/arm/mm/nommu.c:        memblock_reserve(CONFIG_VECTORS_BASE, 2 * PAGE_SIZE);
arch/arm/mm/nommu.c:        early_trap_init((void *)CONFIG_VECTORS_BASE);

To intercept the reset vector for secondary CPUs (because we hide it
away from platforms, so platforms end up hacking around to get at it.)
arch/arm/mach-berlin/platsmp.c:     vectors_base = ioremap(CONFIG_VECTORS_BASE, SZ_32K);

For printing:
arch/arm/mm/init.c:                 MLK(UL(CONFIG_VECTORS_BASE), UL(CONFIG_VECTORS_BASE) +

For dumping the page tables (but since this is only built for MMU=y,
we know what CONFIG_VECTORS_BASE is here.)
arch/arm/mm/dump.c: { CONFIG_VECTORS_BASE,     "Vectors" },
arch/arm/mm/dump.c: { CONFIG_VECTORS_BASE + PAGE_SIZE * 2, "Vectors End" },

For the Berlin and mm/dump code, we could very easily just have a
#define VECTORS_BASE 0xffff0000 in a header file and drop the CONFIG_
prefix.

The MMU case does have to cater for CPUs wanting vectors at 0xffff0000
and at 0x00000000, and this is handled via the page tables - but this
has nothing to do with CONFIG_VECTORS_BASE.  CONFIG_VECTORS_BASE
exists primarily for noMMU.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH WIP 4/4] ARM: remove compile time vector base for CP15 case

[Afzal Mohammed]

Hi,

On Sat, Jan 07, 2017 at 05:38:32PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 07, 2017 at 10:52:28PM +0530, afzal mohammed wrote:

> > TODO:
> > Kill off VECTORS_BASE completely - this would require to handle MMU
> >  case as well as ARM_MPU scenario dynamically.

> Why do you think MMU doesn't already handle it?

i meant here w.r.t displaying vector base address in
arch/arm/mm/init.c, i.e. dynamically get it based on Hivecs setting as
either 0xffff0000 or 0x00000000
> 
> >  config VECTORS_BASE
> >  	hex
> > -	default 0xffff0000 if MMU || CPU_HIGH_VECTOR
> > -	default DRAM_BASE if REMAP_VECTORS_TO_RAM
> > +	default 0xffff0000 if MMU
> >  	default 0x00000000
> 
> When MMU=y, the resulting VECTORS_BASE is always 0xffff0000.  The only
> case where this ends up zero after your change is when MMU=n.

> The MMU case does have to cater for CPUs wanting vectors at 0xffff0000
> and at 0x00000000, and this is handled via the page tables - but this
> has nothing to do with CONFIG_VECTORS_BASE.  CONFIG_VECTORS_BASE
> exists primarily for noMMU.

i had thought that for MMU case if Hivecs is not enabled,
CONFIG_VECTOR_BASE has to be considered as 0x00000000 at least for the
purpose of displaying exception base address.

One thing i have not yet understood is how CPU can take exception with
it base address as 0x00000000 (for Hivecs not enabled case) virtual
address as it is below Kernel memory map.

> For the Berlin and mm/dump code, we could very easily just have a
> #define VECTORS_BASE 0xffff0000 in a header file and drop the CONFIG_
> prefix.

Okay, thanks for the tip.

Regards
afzal

Re: [PATCH WIP 4/4] ARM: remove compile time vector base for CP15 case

[Afzal Mohammed]

Hi,

On Sat, Jan 07, 2017 at 11:32:27PM +0530, Afzal Mohammed wrote:

> i had thought that for MMU case if Hivecs is not enabled,
> CONFIG_VECTOR_BASE has to be considered as 0x00000000 at least for the

s/CONFIG_VECTOR_BASE/exception base address

> purpose of displaying exception base address.

Regards
afzal

Re: [PATCH WIP 4/4] ARM: remove compile time vector base for CP15 case

[Russell King - ARM Linux]

On Sat, Jan 07, 2017 at 11:32:27PM +0530, Afzal Mohammed wrote:
> Hi,
> 
> On Sat, Jan 07, 2017 at 05:38:32PM +0000, Russell King - ARM Linux wrote:
> > On Sat, Jan 07, 2017 at 10:52:28PM +0530, afzal mohammed wrote:
> 
> > > TODO:
> > > Kill off VECTORS_BASE completely - this would require to handle MMU
> > >  case as well as ARM_MPU scenario dynamically.
> 
> > Why do you think MMU doesn't already handle it?
> 
> i meant here w.r.t displaying vector base address in
> arch/arm/mm/init.c, i.e. dynamically get it based on Hivecs setting as
> either 0xffff0000 or 0x00000000

You mean:

        pr_notice("Virtual kernel memory layout:\n"
                        "    vector  : 0x%08lx - 0x%08lx   (%4ld kB)\n"
...
                        MLK(UL(CONFIG_VECTORS_BASE), UL(CONFIG_VECTORS_BASE) +
                                (PAGE_SIZE)),

As I've said, CONFIG_VECTORS_BASE is _always_ 0xffff0000 on MMU, so
this always displays 0xffff0000 - 0xffff1000 here.

> i had thought that for MMU case if Hivecs is not enabled,
> CONFIG_VECTOR_BASE has to be considered as 0x00000000 at least for the
> purpose of displaying exception base address.
> 
> One thing i have not yet understood is how CPU can take exception with
> it base address as 0x00000000 (for Hivecs not enabled case) virtual
> address as it is below Kernel memory map.

Older ARM CPUs without the V bit (ARMv3 and early ARMv4) expect the
vectors to be at virtual address zero.

Most of these systems place ROM at physical address 0, so when the CPU
starts from reset (with the MMU off) it starts executing from ROM.  Once
the MMU is initialised, RAM can be placed there and the ROM vectors
replaced.  The side effect of this is that NULL pointer dereferences
are not always caught... of course, it makes sense that the page at
address 0 is write protected even from the kernel, so a NULL pointer
write dereference doesn't corrupt the vectors.

How we handle it in Linux is that we always map the page for the vectors
at 0xffff0000, and then only map that same page at 0x00000000 if we have
a CPU that needs it there.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH WIP 4/4] ARM: remove compile time vector base for CP15 case

[Afzal Mohammed]

Hi,

On Sat, Jan 07, 2017 at 06:24:15PM +0000, Russell King - ARM Linux wrote:

> As I've said, CONFIG_VECTORS_BASE is _always_ 0xffff0000 on MMU, so
> this always displays 0xffff0000 - 0xffff1000 here.

> Older ARM CPUs without the V bit (ARMv3 and early ARMv4) expect the
> vectors to be at virtual address zero.
> 
> Most of these systems place ROM at physical address 0, so when the CPU
> starts from reset (with the MMU off) it starts executing from ROM.  Once
> the MMU is initialised, RAM can be placed there and the ROM vectors
> replaced.  The side effect of this is that NULL pointer dereferences
> are not always caught... of course, it makes sense that the page at
> address 0 is write protected even from the kernel, so a NULL pointer
> write dereference doesn't corrupt the vectors.
> 
> How we handle it in Linux is that we always map the page for the vectors
> at 0xffff0000, and then only map that same page at 0x00000000 if we have
> a CPU that needs it there.

Thanks for the information, i was not aware, seems that simplifies MMU
case handling.

arch/arm/mm/mmu.c:

	if (!vectors_high()) {
		map.virtual = 0;
		map.length = PAGE_SIZE * 2;
		map.type = MT_LOW_VECTORS;
		create_mapping(&map);
	}



arch/arm/include/asm/cp15.h:

#if __LINUX_ARM_ARCH__ >= 4
#define vectors_high()	(get_cr() & CR_V)
#else
#define vectors_high()	(0)
#endif

Deducing from your reply & above code snippets that for
__LINUX_ARM_ARCH__ >= 4, in all practical cases, vector_high() returns
true

Regards
afzal

Re: [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM

[Afzal Mohammed]

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

Re: [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM

[Vladimir Murzin]

Hi,

On 15/01/17 11:47, Afzal Mohammed wrote:
> 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.
> 

It is not redundant. MPU setup is done it two steps. The first step done in
asm to enable caches, there only kernel image is covered; the second step takes
care on the whole RAM given via dt or "mem=" parameter.

I think other regions are kept there to avoid C side dancing in case of SMP.

>> & 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.

I have wip patches on reworking MPU setup code. The idea is to start using
mpu_rgn_info[] actively, so asm part for secondariness would just sync-up
content of that array. Additionally, it seems that we can reuse free MPU slots
to cover memory which is discarded due to MPU alignment restrictions... 

> 
> Vladimir, once changes are done after a revisit, i would need your
> help to test on Cortex-R.

I'm more than happy to help, but currently I have limited bandwidth, so if it
can wait till the next dev cycle I'd try to make MPU rework finished by that
time.

> 
> 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.
> 

Thanks!

Vladimir

> 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
> 

Re: [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM

[Afzal Mohammed]

Hi,

On Mon, Jan 16, 2017 at 09:53:41AM +0000, Vladimir Murzin wrote:
> On 15/01/17 11:47, Afzal Mohammed wrote:

> > 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.
> 
> It is not redundant. MPU setup is done it two steps. The first step done in
> asm to enable caches, there only kernel image is covered; the second step takes
> care on the whole RAM given via dt or "mem=" parameter.

Okay, thanks for the details.

> > 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.
> 
> I have wip patches on reworking MPU setup code. The idea is to start using
> mpu_rgn_info[] actively, so asm part for secondariness would just sync-up
> content of that array. Additionally, it seems that we can reuse free MPU slots
> to cover memory which is discarded due to MPU alignment restrictions... 
> 
> > Vladimir, once changes are done after a revisit, i would need your
> > help to test on Cortex-R.
> 
> I'm more than happy to help, but currently I have limited bandwidth, so if it
> can wait till the next dev cycle I'd try to make MPU rework finished by that
> time.

Okay, please feel free to do MPU rework the way you were planning, you
know more details & have the platform to achieve it with much higher
efficiency than me.

Regards
afzal