| Message ID | 1479806768-39911-12-git-send-email-vladimir.murzin@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tuesday, November 22, 2016 9:26:08 AM CET Vladimir Murzin wrote: > With this patch applied potentially any platform can be built in NOMMU > configurations if CONFIG_EXPERT is selected. However, there is no > guaranty that platform can successfully run such Image. So the main > motivation behind of this patch: > - bring build coverage for NOMMU configurations > - allow known working NOMMU platforms (like R-class) to be used > - pave a way to add support for single address space (aka 1:1 mapping) > for MMU platforms, so they can be usable in NOMMU configurations > > Cc: Hartley Sweeten <hsweeten@visionengravers.com> > Cc: Ryan Mallon <rmallon@gmail.com> > Cc: Tony Lindgren <tony@atomide.com> > Cc: Thierry Reding <thierry.reding@gmail.com> > Cc: Russell King <linux@armlinux.org.uk> > Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> I'd have to give this a spin with my randconfig build setup, I'd rather not introduce build regressions. Have you tried an allmodconfig build with CONFIG_MMU disabled? Can you provide a git tree that I can try pulling in? Another question is what architecture levels and what platforms we want to support without MMU. The only ARMv4/v5 platform we still have that can actually use NOMMU cores is Integrator with its ARM7TDMI, ARM920T and ARM966E core tiles (and possibly others I couldn't immediately find). Do we actually care about them any more now that all the NOMMU world is ARMv7-M? Are there any benefits in running an ARM920T or ARM926E core with MMU disabled, and does this work with your patches? If not, we could limit it to ARMv7-A/R and possibly ARMv6. Depending on how the build tests go, a per-platform opt-in might be easier than having an opt-out for things that don't work. Arnd
On 22/11/16 10:17, Arnd Bergmann wrote: > On Tuesday, November 22, 2016 9:26:08 AM CET Vladimir Murzin wrote: >> With this patch applied potentially any platform can be built in NOMMU >> configurations if CONFIG_EXPERT is selected. However, there is no >> guaranty that platform can successfully run such Image. So the main >> motivation behind of this patch: >> - bring build coverage for NOMMU configurations >> - allow known working NOMMU platforms (like R-class) to be used >> - pave a way to add support for single address space (aka 1:1 mapping) >> for MMU platforms, so they can be usable in NOMMU configurations >> >> Cc: Hartley Sweeten <hsweeten@visionengravers.com> >> Cc: Ryan Mallon <rmallon@gmail.com> >> Cc: Tony Lindgren <tony@atomide.com> >> Cc: Thierry Reding <thierry.reding@gmail.com> >> Cc: Russell King <linux@armlinux.org.uk> >> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> > > I'd have to give this a spin with my randconfig build setup, I'd > rather not introduce build regressions. Have you tried an > allmodconfig build with CONFIG_MMU disabled? I used defconfigs and just got results for allmodconfig apart of complain on isb instruction in arch/arm/kernel/head-nommu.S [1] there are several link time errors [2]. > > Can you provide a git tree that I can try pulling in? > Unfortunately, I can't provide you with git tree at the moment I'll try to do something around this before proposing the next version. > Another question is what architecture levels and what platforms > we want to support without MMU. The only ARMv4/v5 platform we > still have that can actually use NOMMU cores is Integrator > with its ARM7TDMI, ARM920T and ARM966E core tiles (and possibly > others I couldn't immediately find). Do we actually care about > them any more now that all the NOMMU world is ARMv7-M? Are > there any benefits in running an ARM920T or ARM926E core > with MMU disabled, and does this work with your patches? > I don't have such hardware, so I can't acctually test it - it is why "there is no guaranty" :( OTOH, if sombody has these platforms these pathces is a good start to try NOMMU. > If not, we could limit it to ARMv7-A/R and possibly ARMv6. > Depending on how the build tests go, a per-platform opt-in > might be easier than having an opt-out for things that > don't work. > > Arnd > [1] AS arch/arm/kernel/head-nommu.o arch/arm/kernel/head-nommu.S: Assembler messages: arch/arm/kernel/head-nommu.S:223: Error: selected processor does not support ARM mode `isb' arch/arm/kernel/head-nommu.S:231: Error: selected processor does not support ARM mode `isb' arch/arm/kernel/head-nommu.S:235: Error: selected processor does not support ARM mode `isb' arch/arm/kernel/head-nommu.S:244: Error: selected processor does not support ARM mode `isb' arch/arm/kernel/head-nommu.S:248: Error: selected processor does not support ARM mode `isb' arch/arm/kernel/head-nommu.S:258: Error: selected processor does not support ARM mode `isb' arch/arm/kernel/head-nommu.S:265: Error: selected processor does not support ARM mode `isb' make[1]: *** [arch/arm/kernel/head-nommu.o] Error 1 [2] arch/arm/kernel/head-nommu.o: In function `secondary_startup': (.text+0x1c): undefined reference to `__setup_mpu' arch/arm/kernel/head-nommu.o: In function `stext': (.head.text+0x30): undefined reference to `__setup_mpu' arch/arm/kernel/built-in.o: In function `setup_arch': arch/arm/kernel/smccc-call.o:(.init.text+0xa50): undefined reference to `erratum_a15_798181_init' kernel/built-in.o: In function `kimage_free_entry': memremap.c:(.text+0xd3d9c): undefined reference to `arch_phys_to_idmap_offset' kernel/built-in.o: In function `kimage_alloc_page': memremap.c:(.text+0xd4338): undefined reference to `arch_phys_to_idmap_offset' kernel/built-in.o: In function `kimage_alloc_control_pages': memremap.c:(.text+0xd4ac8): undefined reference to `arch_phys_to_idmap_offset' kernel/built-in.o: In function `kimage_load_segment': memremap.c:(.text+0xd4f40): undefined reference to `arch_phys_to_idmap_offset' kernel/built-in.o: In function `crash_free_reserved_phys_range': memremap.c:(.text+0xd50bc): undefined reference to `arch_phys_to_idmap_offset' arch/arm/mach-mediatek/built-in.o: In function `__mtk_smp_prepare_cpus': mediatek.c:(.init.text+0xe8): undefined reference to `secondary_startup_arm' arch/arm/mach-qcom/built-in.o: In function `qcom_smp_prepare_cpus': platsmp.c:(.init.text+0xe8): undefined reference to `secondary_startup_arm' mm/built-in.o: In function `do_mmu_notifier_register': usercopy.c:(.text+0x34d10): undefined reference to `mm_take_all_locks' usercopy.c:(.text+0x34d9c): undefined reference to `mm_drop_all_locks' usercopy.c:(.text+0x34de4): undefined reference to `mm_take_all_locks' make: *** [vmlinux] Error 1 Cheers Vladimir
Hi,
On Tue, Nov 22, 2016 at 04:57:31PM +0000, Vladimir Murzin wrote:
> I used defconfigs
Which defconfig was used ?
multi_v7_defconfig, MMU & SMP disabled - thus spake the compiler,
kernel/built-in.o: In function `kimage_free_entry':
memremap.c:(.text+0x4dafc): undefined reference to
`arch_phys_to_idmap_offset'
memremap.c:(.text+0x4db04): undefined reference to
`arch_phys_to_idmap_offset'
kernel/built-in.o: In function `kimage_alloc_page':
memremap.c:(.text+0x4dbc0): undefined reference to
`arch_phys_to_idmap_offset'
memremap.c:(.text+0x4dbc8): undefined reference to
`arch_phys_to_idmap_offset'
memremap.c:(.text+0x4dc1c): undefined reference to
`arch_phys_to_idmap_offset'
kernel/built-in.o:memremap.c:(.text+0x4dc30): more undefined
references to `arch_phys_to_idmap_offset' follow
multi_v7_defconfig & MMU disabled, stderr was more verbose and was
unhappy with Kconfig dependencies,
warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
MMU)
warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
MMU)
Ulterior motive here is to try !MMU on Cortex A
Regards
afzal
* Vladimir Murzin <vladimir.murzin@arm.com> [161122 08:57]: > On 22/11/16 10:17, Arnd Bergmann wrote: > > Another question is what architecture levels and what platforms > > we want to support without MMU. The only ARMv4/v5 platform we > > still have that can actually use NOMMU cores is Integrator > > with its ARM7TDMI, ARM920T and ARM966E core tiles (and possibly > > others I couldn't immediately find). Do we actually care about > > them any more now that all the NOMMU world is ARMv7-M? Are > > there any benefits in running an ARM920T or ARM926E core > > with MMU disabled, and does this work with your patches? > > > > I don't have such hardware, so I can't acctually test it - it is why "there is > no guaranty" :( OTOH, if sombody has these platforms these pathces is a good > start to try NOMMU. I believe the reason to run them without MMU might be still valid if we ever get mainline Linux kernel working on some 3G/LTE modems for latency reasons. Not that I know of any use cases, but if we have it working we might as well keep it working. Regards, Tony
On Wed, Nov 23, 2016 at 09:18:29PM +0530, Afzal Mohammed wrote: > multi_v7_defconfig & MMU disabled, stderr was more verbose and was > unhappy with Kconfig dependencies, Well, !MMU and multiplatform _are_ exclusive in reality. One of the things we work around in multiplatform is the different physical address space layouts of the platforms, particularly with where RAM is located. That's not possible in !MMU configurations. A kernel built to support every platform in multiplatform will not boot on most of them. So efforts to make !MMU work with multiplatform are IMHO rather misguided. !MMU makes sense with classifications of systems (like the Cortex-M* based systems) but not everything.
Hi, On Wed, Nov 23, 2016 at 07:16:21PM +0000, Russell King - ARM Linux wrote: > Well, !MMU and multiplatform _are_ exclusive in reality. One of the > things we work around in multiplatform is the different physical > address space layouts of the platforms, particularly with where RAM > is located. That's not possible in !MMU configurations. A kernel > built to support every platform in multiplatform will not boot on > most of them. > > So efforts to make !MMU work with multiplatform are IMHO rather > misguided. > > !MMU makes sense with classifications of systems (like the Cortex-M* > based systems) but not everything. Okay, seems you were referring to AUTO_ZRELADDR or if you had something else in mind, please let me know. The plan was to use Image instead of zImage. Here there are 2 platforms, Freescale's, oh no, NXP's, oh no no, Qualcomm's Vybrid (vf610) and TI's Sitara siblings (am335x beagle & am437x). It was thought that though changes might have to be made b/n them, at least it might be easier using same defconfig, thus went by multi_v7. Though have been able to build for !MMU, have not yet been successful in seeing any activity on the console, probably will have to put printascii() into service. Regards afzal
On Thu, Nov 24, 2016 at 10:55:35PM +0530, Afzal Mohammed wrote: > Hi, > > On Wed, Nov 23, 2016 at 07:16:21PM +0000, Russell King - ARM Linux wrote: > > > Well, !MMU and multiplatform _are_ exclusive in reality. One of the > > things we work around in multiplatform is the different physical > > address space layouts of the platforms, particularly with where RAM > > is located. That's not possible in !MMU configurations. A kernel > > built to support every platform in multiplatform will not boot on > > most of them. > > > > So efforts to make !MMU work with multiplatform are IMHO rather > > misguided. > > > > !MMU makes sense with classifications of systems (like the Cortex-M* > > based systems) but not everything. > > Okay, seems you were referring to AUTO_ZRELADDR or if you had > something else in mind, please let me know. No, I'm talking about the kernel proper itself. > The plan was to use Image instead of zImage. Here there are 2 > platforms, Freescale's, oh no, NXP's, oh no no, Qualcomm's Vybrid > (vf610) and TI's Sitara siblings (am335x beagle & am437x). Right, so Freescale's iMX6, RAM starts at 0x10000000, so when building for noMMU, you need to specify DRAM_START as 0x10000000 and DRAM_SIZE to be the appropriate size of RAM. You'll be able to run the same "Image" kernel on the other platforms _if_ and _only_ _if_ they have RAM covering the same region. That's my point - the kernel image will be linked to place its read-write data at a certain location in the address space, and if you have the MMU disabled (or in 1:1 translation mode) you _must_ have RAM at that location. The reason multiplatform works is because we use the MMU to abstract away the differences in the location of RAM on the platform (amongst other things.) Also note that Cortex-A class CPUs don't perform well with the MMU off, because you can't enable the data cache - and you must have the data cache enabled for SMP to be functional, and it's also required for exclusives to work. There's also some cases where "Device, non-shared" must be used to access some devices, which can only be done with the MMU enabled.
Hi, On Thu, Nov 24, 2016 at 05:35:32PM +0000, Russell King - ARM Linux wrote: > Right, so Freescale's iMX6, RAM starts at 0x10000000, so when building > for noMMU, you need to specify DRAM_START as 0x10000000 and DRAM_SIZE > to be the appropriate size of RAM. Hmm.., i had thought that Vybrid's memory mappings starts from 0x80000000 (same TI Sitara's), just rechecked the older boot logs of Vybrid & Data manual, it seems it is @0x80000000, probably iMX6 has a different map. > Also note that Cortex-A class CPUs don't perform well with the MMU > off, because you can't enable the data cache - and you must have the > data cache enabled for SMP to be functional, and it's also required > for exclusives to work. Yes, was aware of the performance degradation due to disabled dcache. Here the platforms at my disposal are all single core - vf610, am335x & am437x (though strictly speaking 2 of them are ARM SMP configurations, but with number of cores as 1). Seems at least from SMP pov, not expecting issues as they are single core (SMP disabled kernel with MMU enabled works on those) > There's also some cases where "Device, non-shared" must be used to > access some devices, which can only be done with the MMU enabled. Thanks for your valuable feedbacks. Regards afzal
On Thu, Nov 24, 2016 at 11:37:51PM +0530, Afzal Mohammed wrote: > Hi, > > On Thu, Nov 24, 2016 at 05:35:32PM +0000, Russell King - ARM Linux wrote: > > > Right, so Freescale's iMX6, RAM starts at 0x10000000, so when building > > for noMMU, you need to specify DRAM_START as 0x10000000 and DRAM_SIZE > > to be the appropriate size of RAM. > > Hmm.., i had thought that Vybrid's memory mappings starts from > 0x80000000 (same TI Sitara's), just rechecked the older boot logs of > Vybrid & Data manual, it seems it is @0x80000000, probably iMX6 has a > different map. Right, so if you build a multiplatform kernel which covers TI Sitara and iMX6, then you have a choice: - Set DRAM_START to 0x10000000, and have a kernel which will boot on iMX6 but fail on TI Sitara. - Set DRAM_START to 0x80000000, and have a kernel which will boot on TI Sitara, but fail on iMX6 with less than 2GiB of memory (0x70000000 bytes to be exact.) This is why multiplatform doesn't make sense for noMMU - you can't actually build a multiplatform kernel that will work across all these platforms. You'd have to re-link it (at the very least) to place the data section elsewhere in physical memory to make it work. It's this reason that I don't like removing the "depends on MMU" from multiplatform - it gives the incorrect impression that we _can_ support a wide range of systems, but what it will lead to is a kernel that will work on some platforms but not others. The result will be more "bug" reports because the kernel fails to boot... In any case, I think kernelci and similar would first need to be updated to avoid trying to boot noMMU kernels on hardware which it just can't boot on - we _really_ do not want to be randomly scribbling into physical memory, potentially hitting devices, especially with devices that contain OTP fuses that set options as security features.
On 24/11/16 18:45, Russell King - ARM Linux wrote: > It's this reason that I don't like removing the "depends on MMU" from > multiplatform - it gives the incorrect impression that we _can_ support > a wide range of systems, but what it will lead to is a kernel that will > work on some platforms but not others. The result will be more "bug" > reports because the kernel fails to boot... Do you think extra guarding with CONFIG_EXPERIMENTAL would be appropriate to reduce number of such reports? Cheers Vladimir
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f9ff570..8e7496c 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -327,9 +327,9 @@ choice config ARCH_MULTIPLATFORM bool "Allow multiple platforms to be selected" - depends on MMU + depends on MMU || EXPERT select ARM_HAS_SG_CHAIN - select ARM_PATCH_PHYS_VIRT + select ARM_PATCH_PHYS_VIRT if MMU select AUTO_ZRELADDR select CLKSRC_OF select COMMON_CLK
With this patch applied potentially any platform can be built in NOMMU configurations if CONFIG_EXPERT is selected. However, there is no guaranty that platform can successfully run such Image. So the main motivation behind of this patch: - bring build coverage for NOMMU configurations - allow known working NOMMU platforms (like R-class) to be used - pave a way to add support for single address space (aka 1:1 mapping) for MMU platforms, so they can be usable in NOMMU configurations Cc: Hartley Sweeten <hsweeten@visionengravers.com> Cc: Ryan Mallon <rmallon@gmail.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Russell King <linux@armlinux.org.uk> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> --- arch/arm/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)