| Message ID | 20180618141905.7789-5-gerg@linux-m68k.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Greg, CC Chris, Arnd, Nicolas On Mon, Jun 18, 2018 at 4:21 PM Greg Ungerer <gerg@linux-m68k.org> wrote: > Allow the arm versatile machine to be configured for no-MMU operation. > > Older kernels had the ability to build the versatile machine with the MMU > disabled (!CONFIG_MMU). Recent changes to convert the versatile machine > to device tree lost this ability. (Although older kernels could be built > they did not run due to a bug in the IO_ADDRESS() mapping on this machine). > > The motivation for this is that the versatile machine is well supported > in qemu. And this provides an excellent platform for development and > testing no-MMU support on ARM in general. > > This patch adds a versatile platform selection in the upper level arm > system type menu - where it appeared in older kernel versions - when > configuring for the no-MMU case. There is no visible change to the way > versatile is selected for the MMU enabled case. > > Signed-off-by: Greg Ungerer <gerg@linux-m68k.org> Thanks for your patch! I'm happy to see nommu spreading ;-) > --- > arch/arm/Kconfig | 11 +++++++++++ > arch/arm/Kconfig.debug | 3 ++- > arch/arm/mach-versatile/Kconfig | 5 +++-- > 3 files changed, 16 insertions(+), 3 deletions(-) > > v2: don't use a multiplatform setup, move versatile choice to top level menu > v3: rebase on top of linux-4.10 > v3: rebase on top of linux-4.17 > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 54eeb8d00bc6..0608a6a32fac 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -356,6 +356,17 @@ config ARM_SINGLE_ARMV7M > select SPARSE_IRQ > select USE_OF > > +config ARM_SINGLE_ARCH_VERSATILE > + bool "ARM Ltd. Versatile family" > + depends on !MMU > + select AUTO_ZRELADDR > + select CLKSRC_OF > + select COMMON_CLK > + select GENERIC_CLOCKEVENTS > + select GPIOLIB > + select SPARSE_IRQ > + select USE_OF > + I'm afraid adding (duplicating) machine entries for nommu support is not a sustainable solutions. Any machine can run a nommu kernel, in theory. I'm aware of the objection "but you cannot build a nommu kernel that can boot on multiple systems". That's true (unless RAM/FLASH addresses are the same). So don't do that. All of the above is true for XIP, too, hence applies with s/nommu/XIP/. One more reason not to have this duplication. The current "ARM multiplatform" has actually two meanings: 1. It groups platforms that follow the "ARM multiplatform" framework, 2. It allows to build a single kernel that can be booted on multiple platforms. To avoid the duplication, I think 2 should be relaxed when specialized options like XIP or NOMMU are selected. I've just sent a patch to do that. > config ARCH_EBSA110 > bool "EBSA-110" > select ARCH_USES_GETTIMEOFFSET > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > index 693f84392f1b..242a0f744c8a 100644 > --- a/arch/arm/Kconfig.debug > +++ b/arch/arm/Kconfig.debug > @@ -1836,7 +1836,8 @@ config DEBUG_UNCOMPRESS > config UNCOMPRESS_INCLUDE > string > default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \ > - PLAT_SAMSUNG || ARM_SINGLE_ARMV7M > + PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \ > + ARM_SINGLE_ARCH_VERSATILE > default "mach/uncompress.h" > > config EARLY_PRINTK > diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig > index f5c275434d6c..06ad999d5978 100644 > --- a/arch/arm/mach-versatile/Kconfig > +++ b/arch/arm/mach-versatile/Kconfig > @@ -1,7 +1,8 @@ > # SPDX-License-Identifier: GPL-2.0 > config ARCH_VERSATILE > - bool "ARM Ltd. Versatile family" > - depends on ARCH_MULTI_V5 > + bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5 > + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARCH_VERSATILE > + default y if ARM_SINGLE_ARCH_VERSATILE > select ARM_AMBA > select ARM_TIMER_SP804 > select ARM_VIC Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
[ adding linux-kbuild for their input ] On Thu, 21 Jun 2018, Geert Uytterhoeven wrote: > I'm afraid adding (duplicating) machine entries for nommu support is not a > sustainable solutions. Any machine can run a nommu kernel, in theory. > > I'm aware of the objection "but you cannot build a nommu kernel that can > boot on multiple systems". That's true (unless RAM/FLASH addresses are the > same). So don't do that. > > All of the above is true for XIP, too, hence applies with s/nommu/XIP/. > One more reason not to have this duplication. > > The current "ARM multiplatform" has actually two meanings: > 1. It groups platforms that follow the "ARM multiplatform" framework, > 2. It allows to build a single kernel that can be booted on multiple > platforms. > To avoid the duplication, I think 2 should be relaxed when specialized > options like XIP or NOMMU are selected. > > I've just sent a patch to do that. Your patch isn't wrong per se. But it is not enough. The issue here would be easily fixed with some kconfig extension so that: - If XIP or NOMMU is selected then only one target in the multiplatform set can be selected, basically turning it into a choice menu. - If more than one multiplatform targets is selected then XIP and NOMMU can no longere be selected. I don't know how this could be expressed but the implementation might not be that hard. Nicolas
On Thursday, June 21, 2018 1, Nicolas Pitre wrote: > > I've just sent a patch to do that. > > Your patch isn't wrong per se. But it is not enough. The issue here > would be easily fixed with some kconfig extension so that: > > - If XIP or NOMMU is selected then only one target in the multiplatform > set can be selected, basically turning it into a choice menu. > > - If more than one multiplatform targets is selected then XIP and NOMMU > can no longere be selected. > Over the years I tried to tackle this issue in multiple different ways, while still staying in the limitations of kbuild. Basically, everything was shot down for one reason or another (or the only way to do it is really ugly...so I didn't even ask). kbuild doesn't really have a mutually exclusive property that can be dynamically set/cleared. In the end, I saw only 2 paths for adding XIP to ARM MMU builds: 1) Modify kbuild to give the ability as stated above. 2) Make XIP builds somehow be able to run at multiple physical address by modifying the binaries post-build (Arnd's suggestion). What I have been doing is simply applying this patch to arch/arm/Kconifg before every XIP KERNEL build: config XIP_KERNEL bool "Kernel Execute-In-Place from ROM" - depends on !ARM_LPAE && !ARCH_MULTIPLATFORM + depends on !ARM_LPAE help Execute-In-Place allows the kernel to run from non-volatile storage directly addressable by the CPU, such as NOR flash. This saves RAM Chris
Hi Geert, On 22/06/18 01:59, Geert Uytterhoeven wrote: > CC Chris, Arnd, Nicolas > On Mon, Jun 18, 2018 at 4:21 PM Greg Ungerer <gerg@linux-m68k.org> wrote: >> Allow the arm versatile machine to be configured for no-MMU operation. >> >> Older kernels had the ability to build the versatile machine with the MMU >> disabled (!CONFIG_MMU). Recent changes to convert the versatile machine >> to device tree lost this ability. (Although older kernels could be built >> they did not run due to a bug in the IO_ADDRESS() mapping on this machine). >> >> The motivation for this is that the versatile machine is well supported >> in qemu. And this provides an excellent platform for development and >> testing no-MMU support on ARM in general. >> >> This patch adds a versatile platform selection in the upper level arm >> system type menu - where it appeared in older kernel versions - when >> configuring for the no-MMU case. There is no visible change to the way >> versatile is selected for the MMU enabled case. >> >> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org> > > Thanks for your patch! I'm happy to see nommu spreading ;-) Not sure if it is a good thing or not :-) >> --- >> arch/arm/Kconfig | 11 +++++++++++ >> arch/arm/Kconfig.debug | 3 ++- >> arch/arm/mach-versatile/Kconfig | 5 +++-- >> 3 files changed, 16 insertions(+), 3 deletions(-) >> >> v2: don't use a multiplatform setup, move versatile choice to top level menu >> v3: rebase on top of linux-4.10 >> v3: rebase on top of linux-4.17 >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index 54eeb8d00bc6..0608a6a32fac 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -356,6 +356,17 @@ config ARM_SINGLE_ARMV7M >> select SPARSE_IRQ >> select USE_OF >> >> +config ARM_SINGLE_ARCH_VERSATILE >> + bool "ARM Ltd. Versatile family" >> + depends on !MMU >> + select AUTO_ZRELADDR >> + select CLKSRC_OF >> + select COMMON_CLK >> + select GENERIC_CLOCKEVENTS >> + select GPIOLIB >> + select SPARSE_IRQ >> + select USE_OF >> + > > I'm afraid adding (duplicating) machine entries for nommu support is not a > sustainable solutions. Any machine can run a nommu kernel, in theory. I don't disagree with you, my first patch for this did not duplicate the machine type: https://patchwork.kernel.org/patch/9350033/ Vladimir Murzin had an alternative that also didn't duplicate machines: https://www.spinics.net/lists/arm-kernel/msg546837.html But subsequent discussions didn't really get to a final solution: https://patchwork.kernel.org/patch/9464017/ Regards Greg > I'm aware of the objection "but you cannot build a nommu kernel that can > boot on multiple systems". That's true (unless RAM/FLASH addresses are the > same). So don't do that. > > All of the above is true for XIP, too, hence applies with s/nommu/XIP/. > One more reason not to have this duplication. > > The current "ARM multiplatform" has actually two meanings: > 1. It groups platforms that follow the "ARM multiplatform" framework, > 2. It allows to build a single kernel that can be booted on multiple > platforms. > To avoid the duplication, I think 2 should be relaxed when specialized > options like XIP or NOMMU are selected. > > I've just sent a patch to do that. > >> config ARCH_EBSA110 >> bool "EBSA-110" >> select ARCH_USES_GETTIMEOFFSET >> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug >> index 693f84392f1b..242a0f744c8a 100644 >> --- a/arch/arm/Kconfig.debug >> +++ b/arch/arm/Kconfig.debug >> @@ -1836,7 +1836,8 @@ config DEBUG_UNCOMPRESS >> config UNCOMPRESS_INCLUDE >> string >> default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \ >> - PLAT_SAMSUNG || ARM_SINGLE_ARMV7M >> + PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \ >> + ARM_SINGLE_ARCH_VERSATILE >> default "mach/uncompress.h" >> >> config EARLY_PRINTK >> diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig >> index f5c275434d6c..06ad999d5978 100644 >> --- a/arch/arm/mach-versatile/Kconfig >> +++ b/arch/arm/mach-versatile/Kconfig >> @@ -1,7 +1,8 @@ >> # SPDX-License-Identifier: GPL-2.0 >> config ARCH_VERSATILE >> - bool "ARM Ltd. Versatile family" >> - depends on ARCH_MULTI_V5 >> + bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5 >> + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARCH_VERSATILE >> + default y if ARM_SINGLE_ARCH_VERSATILE >> select ARM_AMBA >> select ARM_TIMER_SP804 >> select ARM_VIC > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds >
Hi Chris, On Thu, Jun 21, 2018 at 6:45 PM Chris Brandt <Chris.Brandt@renesas.com> wrote: > On Thursday, June 21, 2018 1, Nicolas Pitre wrote: > > > I've just sent a patch to do that. > > > > Your patch isn't wrong per se. But it is not enough. The issue here > > would be easily fixed with some kconfig extension so that: > > > > - If XIP or NOMMU is selected then only one target in the multiplatform > > set can be selected, basically turning it into a choice menu. > > > > - If more than one multiplatform targets is selected then XIP and NOMMU > > can no longere be selected. > > Over the years I tried to tackle this issue in multiple different ways, > while still staying in the limitations of kbuild. > Basically, everything was shot down for one reason or another (or the > only way to do it is really ugly...so I didn't even ask). > > kbuild doesn't really have a mutually exclusive property that can be > dynamically set/cleared. > > In the end, I saw only 2 paths for adding XIP to ARM MMU builds: > > 1) Modify kbuild to give the ability as stated above. Would that actually help, or would it only give you a false feeling of safety? Most "multiplatform" sub-architectures (like iMX or "shmobile") still have multiple families and SoCs, so you have to repeat the exercise at that level. Still, even when configuring a kernel for a single SoC, the final board selection is at the DTS level. Conclusion: If you want NOMMU and/or XIP, you have to know what you're doing, and hand-holding at whatever level may not save you from making mistakes. > 2) Make XIP builds somehow be able to run at multiple physical address > by modifying the binaries post-build (Arnd's suggestion). That's actually an interesting one: no manual configuration (iff parameters would be extracted from the DTB), so nothing can go wrong ;-) I guess it applies to NOMMU, too. Gr{oetje,eeting}s, Geert
On Thu, Jun 21, 2018 at 05:59:54PM +0200, Geert Uytterhoeven wrote: > Hi Greg, > > CC Chris, Arnd, Nicolas > > On Mon, Jun 18, 2018 at 4:21 PM Greg Ungerer <gerg@linux-m68k.org> wrote: > > Allow the arm versatile machine to be configured for no-MMU operation. > > > > Older kernels had the ability to build the versatile machine with the MMU > > disabled (!CONFIG_MMU). Recent changes to convert the versatile machine > > to device tree lost this ability. (Although older kernels could be built > > they did not run due to a bug in the IO_ADDRESS() mapping on this machine). > > > > The motivation for this is that the versatile machine is well supported > > in qemu. And this provides an excellent platform for development and > > testing no-MMU support on ARM in general. > > > > This patch adds a versatile platform selection in the upper level arm > > system type menu - where it appeared in older kernel versions - when > > configuring for the no-MMU case. There is no visible change to the way > > versatile is selected for the MMU enabled case. > > > > Signed-off-by: Greg Ungerer <gerg@linux-m68k.org> > > Thanks for your patch! I'm happy to see nommu spreading ;-) > > > > --- > > arch/arm/Kconfig | 11 +++++++++++ > > arch/arm/Kconfig.debug | 3 ++- > > arch/arm/mach-versatile/Kconfig | 5 +++-- > > 3 files changed, 16 insertions(+), 3 deletions(-) > > > > v2: don't use a multiplatform setup, move versatile choice to top level menu > > v3: rebase on top of linux-4.10 > > v3: rebase on top of linux-4.17 > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index 54eeb8d00bc6..0608a6a32fac 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -356,6 +356,17 @@ config ARM_SINGLE_ARMV7M > > select SPARSE_IRQ > > select USE_OF > > > > +config ARM_SINGLE_ARCH_VERSATILE > > + bool "ARM Ltd. Versatile family" > > + depends on !MMU > > + select AUTO_ZRELADDR > > + select CLKSRC_OF > > + select COMMON_CLK > > + select GENERIC_CLOCKEVENTS > > + select GPIOLIB > > + select SPARSE_IRQ > > + select USE_OF > > + > > I'm afraid adding (duplicating) machine entries for nommu support is not a > sustainable solutions. Any machine can run a nommu kernel, in theory. Sorry, I strongly disagree. You may be right "in theory" but theory is useless when in practice you _can't_ because of the radically different physical memory layouts. I don't care about "but in theory" crap - we have to deal with reality, and the reality is that ARM platforms are diverse in their physical memory layouts. So, violent NAK on reusing MULTIPLATFORM for XIP/NOMMU.
On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote: > [ adding linux-kbuild for their input ] > > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote: > > > I'm afraid adding (duplicating) machine entries for nommu support is not a > > sustainable solutions. Any machine can run a nommu kernel, in theory. > > > > I'm aware of the objection "but you cannot build a nommu kernel that can > > boot on multiple systems". That's true (unless RAM/FLASH addresses are the > > same). So don't do that. > > > > All of the above is true for XIP, too, hence applies with s/nommu/XIP/. > > One more reason not to have this duplication. > > > > The current "ARM multiplatform" has actually two meanings: > > 1. It groups platforms that follow the "ARM multiplatform" framework, > > 2. It allows to build a single kernel that can be booted on multiple > > platforms. > > To avoid the duplication, I think 2 should be relaxed when specialized > > options like XIP or NOMMU are selected. > > > > I've just sent a patch to do that. > > Your patch isn't wrong per se. But it is not enough. The issue here > would be easily fixed with some kconfig extension so that: > > - If XIP or NOMMU is selected then only one target in the multiplatform > set can be selected, basically turning it into a choice menu. I don't think that's how it should work. Consider the V7M case, where we have better standardisation of the physical address layout than previous ARM devices. We have three platforms which are V7M compliant: - AT91 - iMX - STM32 These have separate symbols: menuconfig ARCH_AT91 bool "AT91/Microchip SoCs" depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M menuconfig ARCH_MXC bool "Freescale i.MX family" depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M menuconfig ARCH_STM32 bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7 With your suggestion, you would become only build a kernel for one of these, but that is not the case today: it's possible to build a single kernel which supports all these platforms. So, I don't think we want your suggestion. What we have today is flexible enough that we can have the best of multiplatform vs the restrictions caused by the variance in hardware. IOW, what we have is a compromise, which I believe is a reasonable, functional, and good compromise that fits the real world physical conditions with the least amount of overhead. Every other suggestion I've seen posted has drawbacks, from artificially restricting what can be selected (eg, as in your case) to allowing more platforms to be selected thereby creating non-bootable kernels (eg, as in Geert's case.)
Hi Geert, On Friday, June 22, 2018, Geert Uytterhoeven wrote: > > 1) Modify kbuild to give the ability as stated above. > > Would that actually help, or would it only give you a false feeling of > safety? Yup! But I don't really care about safty. I just want to be able to build my images without having to hack Kconfig. > Conclusion: If you want NOMMU and/or XIP, you have to know what you're > doing, > and hand-holding at whatever level may not save you from making mistakes. I agree. And, you'll require your own kernel config in order to cut out all the extra stuff that your system doesn't need. > > 2) Make XIP builds somehow be able to run at multiple physical address > > by modifying the binaries post-build (Arnd's suggestion). > > That's actually an interesting one: no manual configuration (iff > parameters > would be extracted from the DTB), so nothing can go wrong ;-) > I guess it applies to NOMMU, too. For the hard coded memory address, it's only need at the very beginning of boot in order to set up a temporary stack, but soon the DTB is read and life is good. So in theory, the memory address could be passed in with a register. For the hard coded ROM address, that needs to be available at run time in order to do the virt_to_phys translation. But, the idea is to change that from a #define to a global variable. It sounded like it might work...although I never got around to hacking the code to see if it would or not because at the end of the day, it didn't provide any real value to ab XIP Linux system. Chris
On Fri, 22 Jun 2018, Russell King - ARM Linux wrote: > On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote: > > [ adding linux-kbuild for their input ] > > > > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote: > > > > > I've just sent a patch to do that. > > > > Your patch isn't wrong per se. But it is not enough. The issue here > > would be easily fixed with some kconfig extension so that: > > > > - If XIP or NOMMU is selected then only one target in the multiplatform > > set can be selected, basically turning it into a choice menu. > > I don't think that's how it should work. Consider the V7M case, where > we have better standardisation of the physical address layout than > previous ARM devices. We have three platforms which are V7M compliant: > > - AT91 > - iMX > - STM32 > > These have separate symbols: > > menuconfig ARCH_AT91 > bool "AT91/Microchip SoCs" > depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M > > menuconfig ARCH_MXC > bool "Freescale i.MX family" > depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M > > menuconfig ARCH_STM32 > bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7 > > With your suggestion, you would become only build a kernel for one of > these, but that is not the case today: it's possible to build a single > kernel which supports all these platforms. That is still something that could be accommodated if the kconfig language was more accommodating. The problem comes from the fact that some options are mutually exclusive, like platforms with conflicting memory maps and XIP. Leaving your example above aside for the moment, let's just pick the ARCH_MULTIPLATFORM group which is always the problematic one in practice. We need a way to limit platform selection within that set to only one platform among them all if XIP_KERNEL is set. And that is impossible to express with the kconfig language today. So, my assertion is that, unless someone volunteers a solution to the kconfig language to express mutual exclusion between symbols, this issue just can't be fixed properly. Nicolas
Hi Nicolas, On Fri, Jun 22, 2018 at 5:26 PM Nicolas Pitre <nicolas.pitre@linaro.org> wrote: > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote: > > On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote: > > > [ adding linux-kbuild for their input ] > > > > > > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote: > > > > I've just sent a patch to do that. > > > > > > Your patch isn't wrong per se. But it is not enough. The issue here > > > would be easily fixed with some kconfig extension so that: > > > > > > - If XIP or NOMMU is selected then only one target in the multiplatform > > > set can be selected, basically turning it into a choice menu. > > > > I don't think that's how it should work. Consider the V7M case, where > > we have better standardisation of the physical address layout than > > previous ARM devices. We have three platforms which are V7M compliant: > > > > - AT91 > > - iMX > > - STM32 > > > > These have separate symbols: > > > > menuconfig ARCH_AT91 > > bool "AT91/Microchip SoCs" > > depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M > > > > menuconfig ARCH_MXC > > bool "Freescale i.MX family" > > depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M > > > > menuconfig ARCH_STM32 > > bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7 > > > > With your suggestion, you would become only build a kernel for one of > > these, but that is not the case today: it's possible to build a single > > kernel which supports all these platforms. > > That is still something that could be accommodated if the kconfig > language was more accommodating. The problem comes from the fact that > some options are mutually exclusive, like platforms with conflicting > memory maps and XIP. > > Leaving your example above aside for the moment, let's just pick the > ARCH_MULTIPLATFORM group which is always the problematic one in > practice. We need a way to limit platform selection within that set to > only one platform among them all if XIP_KERNEL is set. And that is > impossible to express with the kconfig language today. > > So, my assertion is that, unless someone volunteers a solution to the > kconfig language to express mutual exclusion between symbols, this issue > just can't be fixed properly. Even that would not be sufficient, as these days the final target platform selection is not by a Kconfig symbol, but by a DT[SB] file. Gr{oetje,eeting}s, Geert
On Fri, 22 Jun 2018, Geert Uytterhoeven wrote: > Hi Nicolas, > > On Fri, Jun 22, 2018 at 5:26 PM Nicolas Pitre <nicolas.pitre@linaro.org> wrote: > > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote: > > > On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote: > > > > [ adding linux-kbuild for their input ] > > > > > > > > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote: > > > > > I've just sent a patch to do that. > > > > > > > > Your patch isn't wrong per se. But it is not enough. The issue here > > > > would be easily fixed with some kconfig extension so that: > > > > > > > > - If XIP or NOMMU is selected then only one target in the multiplatform > > > > set can be selected, basically turning it into a choice menu. > > > > > > I don't think that's how it should work. Consider the V7M case, where > > > we have better standardisation of the physical address layout than > > > previous ARM devices. We have three platforms which are V7M compliant: > > > > > > - AT91 > > > - iMX > > > - STM32 > > > > > > These have separate symbols: > > > > > > menuconfig ARCH_AT91 > > > bool "AT91/Microchip SoCs" > > > depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M > > > > > > menuconfig ARCH_MXC > > > bool "Freescale i.MX family" > > > depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M > > > > > > menuconfig ARCH_STM32 > > > bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7 > > > > > > With your suggestion, you would become only build a kernel for one of > > > these, but that is not the case today: it's possible to build a single > > > kernel which supports all these platforms. > > > > That is still something that could be accommodated if the kconfig > > language was more accommodating. The problem comes from the fact that > > some options are mutually exclusive, like platforms with conflicting > > memory maps and XIP. > > > > Leaving your example above aside for the moment, let's just pick the > > ARCH_MULTIPLATFORM group which is always the problematic one in > > practice. We need a way to limit platform selection within that set to > > only one platform among them all if XIP_KERNEL is set. And that is > > impossible to express with the kconfig language today. > > > > So, my assertion is that, unless someone volunteers a solution to the > > kconfig language to express mutual exclusion between symbols, this issue > > just can't be fixed properly. > > Even that would not be sufficient, as these days the final target platform > selection is not by a Kconfig symbol, but by a DT[SB] file. That is no longer a kernel config/build issue if you the system integrator put an XIP kernel on a target with the wrong DT. The XIP kernel does require that you provide the actual memory base address as a constant to the build system but that could be extracted directly from the DT data if having a kconfig prompt for that is too unwieldy. The new kconfig macro language in mainline could even be leveraged to do that at config time. All that is possible already. But config symbol mutual exclusion is not. Nicolas
On Fri, Jun 22, 2018 at 11:57:32AM -0400, Nicolas Pitre wrote: > That is no longer a kernel config/build issue if you the system > integrator put an XIP kernel on a target with the wrong DT. > > The XIP kernel does require that you provide the actual memory base > address as a constant to the build system but that could be extracted > directly from the DT data if having a kconfig prompt for that is too > unwieldy. The new kconfig macro language in mainline could even be > leveraged to do that at config time. That is actually incorrect - you're too used to the dynamic fixup of virt_to_phys() and friends now! Given that XIP is typically used in environments where the kernel text is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT. When disabled, we use a constant translation, based upon the build-time CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings. The early assembler relies upon these settings - which must be known before we enable the MMU. As such, DT parsing is not available to us at that point (as we can't run any C code, because we won't be calling it at the address it was linked for.) I suppose someone who was sufficiently motivated could write assembly- based parsing of DT to extract the memory regions and work out what the right settings are. Is there really the motivation to do that - there was a burst of XIP interest a few releases ago but it seems to have tailed off.
On Fri, 22 Jun 2018, Russell King - ARM Linux wrote: > On Fri, Jun 22, 2018 at 11:57:32AM -0400, Nicolas Pitre wrote: > > That is no longer a kernel config/build issue if you the system > > integrator put an XIP kernel on a target with the wrong DT. > > > > The XIP kernel does require that you provide the actual memory base > > address as a constant to the build system but that could be extracted > > directly from the DT data if having a kconfig prompt for that is too > > unwieldy. The new kconfig macro language in mainline could even be > > leveraged to do that at config time. > > That is actually incorrect - you're too used to the dynamic fixup of > virt_to_phys() and friends now! > > Given that XIP is typically used in environments where the kernel text > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT. When > disabled, we use a constant translation, based upon the build-time > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings. > > The early assembler relies upon these settings - which must be known > before we enable the MMU. As such, DT parsing is not available to us > at that point (as we can't run any C code, because we won't be calling > it at the address it was linked for.) I think you got me wrong. I meant DT parsing at config or build time, not at run time. Latest mainline allows kconfig files to call out to external programs now. Nicolas
On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote: > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote: > > That is actually incorrect - you're too used to the dynamic fixup of > > virt_to_phys() and friends now! > > > > Given that XIP is typically used in environments where the kernel text > > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT. When > > disabled, we use a constant translation, based upon the build-time > > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings. > > > > The early assembler relies upon these settings - which must be known > > before we enable the MMU. As such, DT parsing is not available to us > > at that point (as we can't run any C code, because we won't be calling > > it at the address it was linked for.) > > I think you got me wrong. I meant DT parsing at config or build time, > not at run time. That seems backwards and complicated. It seems this would end up with: - you configure the kernel - build the dtb files - reconfigure parsing a specific dtb file built in the previous step - build the kernel proper
> That is actually incorrect - you're too used to the dynamic fixup of > virt_to_phys() and friends now! > > Given that XIP is typically used in environments where the kernel text > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT. When > disabled, we use a constant translation, based upon the build-time > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings. CONFIG_PHYS_OFFSET (RAM address) and CONFIG_XIP_PHYS_ADDR (ROM address) are set today in kconfig. Instead of having them hard coded, they could be global variables set during boot. CONFIG_XIP_PHYS_ADDR could be determined by looking at the value of the PC. CONFIG_PHYS_OFFSET is still the issue because that has to be passed in via boot register. > I suppose someone who was sufficiently motivated could write assembly- > based parsing of DT to extract the memory regions and work out what the > right settings are. Is there really the motivation to do that - there > was a burst of XIP interest a few releases ago but it seems to have > tailed off. Because at least for me, by simply removing the !ARCH_MULTIPLATFORM dependency for setting XIP_KERNEL works perfectly fine for building and running kernels. So, it's hard to justify doing a lot more work than what can be done today with just 1 line edit. I still test every kernel release to make XIP_KERNEL still works. Actually, I just tested 4.18.0-rc1 this morning. Chris
On Friday, June 22, 2018 1, Nicolas Pitre wrote:
> All that is possible already. But config symbol mutual exclusion is not.
I still don't understand why we need some false sense of security for
only selecting 1 platform.
There are probably plenty of kernel config options that you could enable
that would break any number of systems.
So, why do we feel that XIP_KERNEL needs a warm safety blanket around
it?
Chris
On Fri, 22 Jun 2018, Russell King - ARM Linux wrote: > On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote: > > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote: > > > That is actually incorrect - you're too used to the dynamic fixup of > > > virt_to_phys() and friends now! > > > > > > Given that XIP is typically used in environments where the kernel text > > > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT. When > > > disabled, we use a constant translation, based upon the build-time > > > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings. > > > > > > The early assembler relies upon these settings - which must be known > > > before we enable the MMU. As such, DT parsing is not available to us > > > at that point (as we can't run any C code, because we won't be calling > > > it at the address it was linked for.) > > > > I think you got me wrong. I meant DT parsing at config or build time, > > not at run time. > > That seems backwards and complicated. It seems this would end up > with: > > - you configure the kernel > - build the dtb files > - reconfigure parsing a specific dtb file built in the previous step > - build the kernel proper ... or just stick the right value manually when prompting for XIP_PHYS_ADDR. Really, depending on DT is a non issue that only pulls the conversation away from the actual kconfig language limitation that needs to be overcome. Nicolas
On Fri, 22 Jun 2018, Chris Brandt wrote: > On Friday, June 22, 2018 1, Nicolas Pitre wrote: > > All that is possible already. But config symbol mutual exclusion is not. > > I still don't understand why we need some false sense of security for > only selecting 1 platform. Because that's the right thing to do. Small hacks are nice, but when they accumulate (and they always do over time) then maintainability suffers. This is why you may do whatever small hacks in your own copy of the kernel code and that might be good enough, but the mainline source tree should be held to higher standards. > There are probably plenty of kernel config options that you could enable > that would break any number of systems. That's no excuse to add more of them. Many people are constantly working to move things in the other direction. > So, why do we feel that XIP_KERNEL needs a warm safety blanket around > it? Because we simply try not to create invalid kernel configurations. XIP_KERNEL is not more special than other symbols in that respect. And if the kconfig language has to be extended for proper configurations to be produced then that's what it is, and trying to cheat around that fact won't produce any good. Nicolas
On Fri, Jun 22, 2018 at 12:54:18PM -0400, Nicolas Pitre wrote: > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote: > > > On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote: > > > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote: > > > > That is actually incorrect - you're too used to the dynamic fixup of > > > > virt_to_phys() and friends now! > > > > > > > > Given that XIP is typically used in environments where the kernel text > > > > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT. When > > > > disabled, we use a constant translation, based upon the build-time > > > > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings. > > > > > > > > The early assembler relies upon these settings - which must be known > > > > before we enable the MMU. As such, DT parsing is not available to us > > > > at that point (as we can't run any C code, because we won't be calling > > > > it at the address it was linked for.) > > > > > > I think you got me wrong. I meant DT parsing at config or build time, > > > not at run time. > > > > That seems backwards and complicated. It seems this would end up > > with: > > > > - you configure the kernel > > - build the dtb files > > - reconfigure parsing a specific dtb file built in the previous step > > - build the kernel proper > > ... or just stick the right value manually when prompting for > XIP_PHYS_ADDR. Really, depending on DT is a non issue that only pulls > the conversation away from the actual kconfig language limitation that > needs to be overcome. Which is _exactly_ what we do today, so I don't see what point you're making in this sub-thread. I thought we were discussing about getting Kconfig to obtain settings from dtb files. If you have a point to make, please don't make the discussion impossible by changing your point, it makes it a waste of time trying to have a discussion.
On Friday, June 22, 2018, Nicolas Pitre wrote: > > So, why do we feel that XIP_KERNEL needs a warm safety blanket around > > it? > > Because we simply try not to create invalid kernel configurations. > XIP_KERNEL is not more special than other symbols in that respect. Then here's a question. To be clear, the discussion is around "Being able to build a kernel that will not boot" So which one of these is more important: build or boot? Meaning what if you can select multiple platforms in kconfig, but then there is a .c file that does more sanity checking that then prevents the full build using a #error. In that case you can never "build" a kernel that has no chance of booting on all the selected platforms. There are configs options today that you can select, but unless some external criteria is met during build time, the build will fail (like with a "missing .h file" message or something) Chris
On Fri, 22 Jun 2018, Russell King - ARM Linux wrote: > On Fri, Jun 22, 2018 at 12:54:18PM -0400, Nicolas Pitre wrote: > > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote: > > > > > On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote: > > > > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote: > > > > > That is actually incorrect - you're too used to the dynamic fixup of > > > > > virt_to_phys() and friends now! > > > > > > > > > > Given that XIP is typically used in environments where the kernel text > > > > > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT. When > > > > > disabled, we use a constant translation, based upon the build-time > > > > > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings. > > > > > > > > > > The early assembler relies upon these settings - which must be known > > > > > before we enable the MMU. As such, DT parsing is not available to us > > > > > at that point (as we can't run any C code, because we won't be calling > > > > > it at the address it was linked for.) > > > > > > > > I think you got me wrong. I meant DT parsing at config or build time, > > > > not at run time. > > > > > > That seems backwards and complicated. It seems this would end up > > > with: > > > > > > - you configure the kernel > > > - build the dtb files > > > - reconfigure parsing a specific dtb file built in the previous step > > > - build the kernel proper > > > > ... or just stick the right value manually when prompting for > > XIP_PHYS_ADDR. Really, depending on DT is a non issue that only pulls > > the conversation away from the actual kconfig language limitation that > > needs to be overcome. > > Which is _exactly_ what we do today, so I don't see what point you're > making in this sub-thread. I was merely trying to show Geert that DT dependencies are not an issue after he brought that as an argument. Nicolas
On Fri, 22 Jun 2018, Chris Brandt wrote: > On Friday, June 22, 2018, Nicolas Pitre wrote: > > > So, why do we feel that XIP_KERNEL needs a warm safety blanket around > > > it? > > > > Because we simply try not to create invalid kernel configurations. > > XIP_KERNEL is not more special than other symbols in that respect. > > Then here's a question. > > To be clear, the discussion is around > > "Being able to build a kernel that will not boot" > > So which one of these is more important: build or boot? Obviously both. Most people are ultimately interested in kernels that can boot. > Meaning what if you can select multiple platforms in kconfig, but then > there is a .c file that does more sanity checking that then prevents the > full build using a #error. Sorry, that is still cheating around the actual issue, which is the inability to properly express mutually exclusive config symbols in kconfig. Nicolas
On Fri, Jun 22, 2018 at 05:23:09PM +0000, Chris Brandt wrote: > Then here's a question. > > To be clear, the discussion is around > > "Being able to build a kernel that will not boot" > > So which one of these is more important: build or boot? We care about both. > Meaning what if you can select multiple platforms in kconfig, but then > there is a .c file that does more sanity checking that then prevents the > full build using a #error. ... which is not acceptable. We have a lot of automated build infrastructure to build almost every commit in the mainline kernel against almost every build configuration that is present in the kernel and every architecture that is present in the mainline kernel. We also have people that build random configurations and fix any build failures and warnings which result from that. I also build randconfigs here. > In that case you can never "build" a kernel that has no chance of > booting on all the selected platforms. > > There are configs options today that you can select, but unless some > external criteria is met during build time, the build will fail (like > with a "missing .h file" message or something) Such as? I don't think that's found by the randconfig builders - I've never noticed any such failures on ARM.
On Friday, June 22, 2018, Russell King - ARM Linux wrote: > > There are configs options today that you can select, but unless some > > external criteria is met during build time, the build will fail (like > > with a "missing .h file" message or something) > > Such as? I don't think that's found by the randconfig builders - I've > never noticed any such failures on ARM. I got this set once by accident after a kernel update CONFIG_SYSTEM_TRUSTED_KEYRING=y which then let me to this error: HOSTCC scripts/extract-cert ../scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory compilation terminated. Regardless, I take your opinion as valid. Chris
Hi Chris, On Fri, Jun 22, 2018 at 10:25 PM Chris Brandt <Chris.Brandt@renesas.com> wrote: > On Friday, June 22, 2018, Russell King - ARM Linux wrote: > > > There are configs options today that you can select, but unless some > > > external criteria is met during build time, the build will fail (like > > > with a "missing .h file" message or something) > > > > Such as? I don't think that's found by the randconfig builders - I've > > never noticed any such failures on ARM. > > I got this set once by accident after a kernel update > > CONFIG_SYSTEM_TRUSTED_KEYRING=y > > which then let me to this error: > > HOSTCC scripts/extract-cert > ../scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory > compilation terminated. Which just means libssl-dev became a build dependency. Gr{oetje,eeting}s, Geert
On Fri, Jun 22, 2018 at 08:25:06PM +0000, Chris Brandt wrote: > On Friday, June 22, 2018, Russell King - ARM Linux wrote: > > > There are configs options today that you can select, but unless some > > > external criteria is met during build time, the build will fail (like > > > with a "missing .h file" message or something) > > > > Such as? I don't think that's found by the randconfig builders - I've > > never noticed any such failures on ARM. > > I got this set once by accident after a kernel update > > CONFIG_SYSTEM_TRUSTED_KEYRING=y > > which then let me to this error: > > HOSTCC scripts/extract-cert > ../scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory > compilation terminated. Hmm. Is that a problem if the documented minimum requirements to build the kernel are violated? It seems the openssl 1.0.0 development package is required to build kernels v4.3 and beyond. Here's what Documentation/process/changes.rst has to say about it: Current Minimal Requirements **************************** ... ====================== =============== ======================================== Program Minimal version Command to check the version ====================== =============== ======================================== openssl & libcrypto 1.0.0 openssl version ... OpenSSL ------- Module signing and external certificate handling use the OpenSSL program and crypto library to do key creation and signature generation. You will need openssl to build kernels 3.7 and higher if module signing is enabled. You will also need openssl development packages to build kernels 4.3 and higher.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 54eeb8d00bc6..0608a6a32fac 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -356,6 +356,17 @@ config ARM_SINGLE_ARMV7M select SPARSE_IRQ select USE_OF +config ARM_SINGLE_ARCH_VERSATILE + bool "ARM Ltd. Versatile family" + depends on !MMU + select AUTO_ZRELADDR + select CLKSRC_OF + select COMMON_CLK + select GENERIC_CLOCKEVENTS + select GPIOLIB + select SPARSE_IRQ + select USE_OF + config ARCH_EBSA110 bool "EBSA-110" select ARCH_USES_GETTIMEOFFSET diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 693f84392f1b..242a0f744c8a 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -1836,7 +1836,8 @@ config DEBUG_UNCOMPRESS config UNCOMPRESS_INCLUDE string default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \ - PLAT_SAMSUNG || ARM_SINGLE_ARMV7M + PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \ + ARM_SINGLE_ARCH_VERSATILE default "mach/uncompress.h" config EARLY_PRINTK diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig index f5c275434d6c..06ad999d5978 100644 --- a/arch/arm/mach-versatile/Kconfig +++ b/arch/arm/mach-versatile/Kconfig @@ -1,7 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 config ARCH_VERSATILE - bool "ARM Ltd. Versatile family" - depends on ARCH_MULTI_V5 + bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5 + depends on ARCH_MULTI_V5 || ARM_SINGLE_ARCH_VERSATILE + default y if ARM_SINGLE_ARCH_VERSATILE select ARM_AMBA select ARM_TIMER_SP804 select ARM_VIC
Allow the arm versatile machine to be configured for no-MMU operation. Older kernels had the ability to build the versatile machine with the MMU disabled (!CONFIG_MMU). Recent changes to convert the versatile machine to device tree lost this ability. (Although older kernels could be built they did not run due to a bug in the IO_ADDRESS() mapping on this machine). The motivation for this is that the versatile machine is well supported in qemu. And this provides an excellent platform for development and testing no-MMU support on ARM in general. This patch adds a versatile platform selection in the upper level arm system type menu - where it appeared in older kernel versions - when configuring for the no-MMU case. There is no visible change to the way versatile is selected for the MMU enabled case. Signed-off-by: Greg Ungerer <gerg@linux-m68k.org> --- arch/arm/Kconfig | 11 +++++++++++ arch/arm/Kconfig.debug | 3 ++- arch/arm/mach-versatile/Kconfig | 5 +++-- 3 files changed, 16 insertions(+), 3 deletions(-) v2: don't use a multiplatform setup, move versatile choice to top level menu v3: rebase on top of linux-4.10 v3: rebase on top of linux-4.17