| Message ID | 1414503095-25986-5-git-send-email-kaixu.xia@linaro.org |
|---|---|
| State | New |
| Headers | show |
On Tue, Oct 28, 2014 at 09:31:34PM +0800, Xia Kaixu wrote: > With the ARCH_MULTIPLATFORM_STRICT option, it becomes much easier to > enable the ERRATA options when we know at configuration time that we > don't care about the generic case. The previous configuration makes > XIP_KERNEL option fundamentally non-MULTIPLATFORM, but it's still > valid to select it when building for !ARCH_MULTIPLATFORM_STRICT and > selecting only the one machine that you want to run on. XIP_KERNEL isn't supported on anything past ARMv5 though. I don't like the case for errata though - we want these errata to be handled by the board firmware, not by the kernel, and we don't want to make it any easier for people to ignore that fact.
On Tuesday 28 October 2014 14:02:31 Russell King - ARM Linux wrote: > On Tue, Oct 28, 2014 at 09:31:34PM +0800, Xia Kaixu wrote: > > With the ARCH_MULTIPLATFORM_STRICT option, it becomes much easier to > > enable the ERRATA options when we know at configuration time that we > > don't care about the generic case. The previous configuration makes > > XIP_KERNEL option fundamentally non-MULTIPLATFORM, but it's still > > valid to select it when building for !ARCH_MULTIPLATFORM_STRICT and > > selecting only the one machine that you want to run on. > > XIP_KERNEL isn't supported on anything past ARMv5 though. I would really like to get some of the platforms that currently use XIP_KERNEL to use ARCH_MULTIPLATFORM in the long run. One of them is EFM32, which is ARMv7-M. > I don't like the case for errata though - we want these errata to be > handled by the board firmware, not by the kernel, and we don't want > to make it any easier for people to ignore that fact. Ok, fair enough. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Tue, Oct 28, 2014 at 03:24:38PM +0100, Arnd Bergmann wrote: > On Tuesday 28 October 2014 14:02:31 Russell King - ARM Linux wrote: > > On Tue, Oct 28, 2014 at 09:31:34PM +0800, Xia Kaixu wrote: > > > With the ARCH_MULTIPLATFORM_STRICT option, it becomes much easier to > > > enable the ERRATA options when we know at configuration time that we > > > don't care about the generic case. The previous configuration makes > > > XIP_KERNEL option fundamentally non-MULTIPLATFORM, but it's still > > > valid to select it when building for !ARCH_MULTIPLATFORM_STRICT and > > > selecting only the one machine that you want to run on. > > > > XIP_KERNEL isn't supported on anything past ARMv5 though. > > I would really like to get some of the platforms that currently use > XIP_KERNEL to use ARCH_MULTIPLATFORM in the long run. One of them > is EFM32, which is ARMv7-M. Right, and on ARMv7-M, the restrictions against XIP_KERNEL don't apply. The restrictions on XIP_KERNEL only apply with MMU-full kernels, because of the remapping needed - the kernel is executed from flash, which is mapped separately, and that mapping needs to be setup in order to turn the MMU on. With ARMv7-M, there is no MMU to worry about, no other mappings are required, so there is no special platform specific setup applicable. So, I don't see any reason why XIP_KERNEL can't depend on !ARCH_MULTIPLATFORM || CPU_V7M.
On Tuesday 28 October 2014 14:31:18 Russell King - ARM Linux wrote: > On Tue, Oct 28, 2014 at 03:24:38PM +0100, Arnd Bergmann wrote: > > On Tuesday 28 October 2014 14:02:31 Russell King - ARM Linux wrote: > > > On Tue, Oct 28, 2014 at 09:31:34PM +0800, Xia Kaixu wrote: > > > > With the ARCH_MULTIPLATFORM_STRICT option, it becomes much easier to > > > > enable the ERRATA options when we know at configuration time that we > > > > don't care about the generic case. The previous configuration makes > > > > XIP_KERNEL option fundamentally non-MULTIPLATFORM, but it's still > > > > valid to select it when building for !ARCH_MULTIPLATFORM_STRICT and > > > > selecting only the one machine that you want to run on. > > > > > > XIP_KERNEL isn't supported on anything past ARMv5 though. > > > > I would really like to get some of the platforms that currently use > > XIP_KERNEL to use ARCH_MULTIPLATFORM in the long run. One of them > > is EFM32, which is ARMv7-M. > > Right, and on ARMv7-M, the restrictions against XIP_KERNEL don't apply. > The restrictions on XIP_KERNEL only apply with MMU-full kernels, because > of the remapping needed - the kernel is executed from flash, which is > mapped separately, and that mapping needs to be setup in order to turn > the MMU on. > > With ARMv7-M, there is no MMU to worry about, no other mappings are > required, so there is no special platform specific setup applicable. > > So, I don't see any reason why XIP_KERNEL can't depend on > !ARCH_MULTIPLATFORM || CPU_V7M. That would solve the problem for V7M, but I also don't see a reason to disallow XIP_KERNEL on a platform that depends on ARCH_MULTIPLATFORM. The main problem is that any ARMv4/v5 platform that currently uses XIP_KERNEL breaks when we do a conversion to ARCH_MULTIPLATFORM, and I think that is bad. The same applies to ZBOOT_ROM, which we should probably treat the same way here. An example for that is the Renesas SH-Mobile SH7372 that can boot directly from MMC. I really want Renesas to convert all of their SH-Mobile machines to multiplatform, just like all other ARMv7 platforms. There is nothing preventing you from running a multiplatform kernel on SH7372 as long as you don't want to load the kernel from MMC without a proper bootloader. I also don't see a reason to take out that feature just because they are migrating to multiplatform (there may or may not be other reasons to deprecate this feature, but that is a different matter). At the moment SH-Mobile can be built either as a standalone platform or as multiplatform, but even now you can build a kernel that uses CONFIG_ZBOOT_ROM_MMCIF and will only ever work on SH7372 but includes all other shmobile targets as well. I don't see anything wrong with that, and I would like to see this keep working when SH7372 is part of ARCH_MULTIPLATFORM, but at the same time think it's good to have ARCH_MULTIPLATFORM_STRICT to prevent this from being selected for a kernel that is supposed to run everywhere. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Tue, Oct 28, 2014 at 03:50:31PM +0100, Arnd Bergmann wrote: > That would solve the problem for V7M, but I also don't see a reason > to disallow XIP_KERNEL on a platform that depends on ARCH_MULTIPLATFORM. > > The main problem is that any ARMv4/v5 platform that currently uses > XIP_KERNEL breaks when we do a conversion to ARCH_MULTIPLATFORM, and > I think that is bad. > > The same applies to ZBOOT_ROM, which we should probably treat the > same way here. An example for that is the Renesas SH-Mobile SH7372 that > can boot directly from MMC. I really want Renesas to convert > all of their SH-Mobile machines to multiplatform, just like all other > ARMv7 platforms. There is nothing preventing you from running a > multiplatform kernel on SH7372 as long as you don't want to load the > kernel from MMC without a proper bootloader. I also don't see a reason > to take out that feature just because they are migrating to multiplatform > (there may or may not be other reasons to deprecate this feature, but that > is a different matter). At the moment SH-Mobile can be built either > as a standalone platform or as multiplatform, but even now you can build > a kernel that uses CONFIG_ZBOOT_ROM_MMCIF and will only ever work on > SH7372 but includes all other shmobile targets as well. > > I don't see anything wrong with that, and I would like to see this > keep working when SH7372 is part of ARCH_MULTIPLATFORM, but at the > same time think it's good to have ARCH_MULTIPLATFORM_STRICT to prevent > this from being selected for a kernel that is supposed to run everywhere. What you're asking for is a multiplatform kernel which can't be run on multiple platforms. Think about that for a while. If you're going to be building an ARMv5 XIP kernel, then it needs to only include support for the ARMv5 SoC which you are targetting. It's no good to think "oh, we can then include other ARMv5 SoCs too" - you can, but the kernel will never run there. That's where the pre-multiplatform setup works well - it ensures that the correct dependencies are there. What we need to do is to combine these two properly such that if you want to build with a feature which limits you to one SoC, then the kernel configuration limits you to exactly that. That's not done by making some magic Kconfig option which disables a load of dependencies but still lets you chuck lots of useless stuff in together. In any case, the thought of an XIP kernel with an allmodconfig config rather misses one of the fundamental problems with XIP multiplatform. If you /ever/ want to write to the flash which the XIP kernel is contained, you must move the interrupt handling code out into RAM, so that when an interrupt happens, you can talk to the flash chip to make the kernel readable again. That takes *all* of the initial interrupt handling code and data into RAM. What that means is that our current IRQ multi-handler solution doesn't work there - and we need a set of platform specific assembly fragments to do this. As I said previously, there's also the complexity in setting up the XIP mappings in the assembly code, which takes quite an amount of knowledge of the physical memory layout on the SoC. Frankly, I think the idea of XIP and multiplatform is a pipedream.
On Tuesday 28 October 2014 15:05:21 Russell King - ARM Linux wrote: > On Tue, Oct 28, 2014 at 03:50:31PM +0100, Arnd Bergmann wrote: > > That would solve the problem for V7M, but I also don't see a reason > > to disallow XIP_KERNEL on a platform that depends on ARCH_MULTIPLATFORM. > > > > The main problem is that any ARMv4/v5 platform that currently uses > > XIP_KERNEL breaks when we do a conversion to ARCH_MULTIPLATFORM, and > > I think that is bad. > > > > The same applies to ZBOOT_ROM, which we should probably treat the > > same way here. An example for that is the Renesas SH-Mobile SH7372 that > > can boot directly from MMC. I really want Renesas to convert > > all of their SH-Mobile machines to multiplatform, just like all other > > ARMv7 platforms. There is nothing preventing you from running a > > multiplatform kernel on SH7372 as long as you don't want to load the > > kernel from MMC without a proper bootloader. I also don't see a reason > > to take out that feature just because they are migrating to multiplatform > > (there may or may not be other reasons to deprecate this feature, but that > > is a different matter). At the moment SH-Mobile can be built either > > as a standalone platform or as multiplatform, but even now you can build > > a kernel that uses CONFIG_ZBOOT_ROM_MMCIF and will only ever work on > > SH7372 but includes all other shmobile targets as well. > > > > I don't see anything wrong with that, and I would like to see this > > keep working when SH7372 is part of ARCH_MULTIPLATFORM, but at the > > same time think it's good to have ARCH_MULTIPLATFORM_STRICT to prevent > > this from being selected for a kernel that is supposed to run everywhere. > > What you're asking for is a multiplatform kernel which can't be run on > multiple platforms. Think about that for a while. > > If you're going to be building an ARMv5 XIP kernel, then it needs to only > include support for the ARMv5 SoC which you are targetting. It's no good > to think "oh, we can then include other ARMv5 SoCs too" - you can, but > the kernel will never run there. > > That's where the pre-multiplatform setup works well - it ensures that the > correct dependencies are there. What we need to do is to combine these > two properly such that if you want to build with a feature which limits > you to one SoC, then the kernel configuration limits you to exactly that. > That's not done by making some magic Kconfig option which disables a load > of dependencies but still lets you chuck lots of useless stuff in together. Part of the underlying problem here is really that Kconfig isn't able to express the set of dependencies. It already fails to do that for a platform that supports multiple boards and you want to build an XIP kernel for one of the boards. What you would want to express is that either - as soon as XIP_KERNEL is set, you can only enable boards that have the exact same ROM address for running the kernel from (usually just one board), or - the XIP_KERNEL option disappears when you enable multiple boards that are mutually incompatible whenever XIP is enabled. We don't do either at the moment, and I've tried to come up with a way to express this in Kconfig and haven't found one. Allowing the multiple mach-* directories to behave the same way as multiple boards in a single platform do today is not a fundamental change, but more a consequence of generally being able to build them together. > In any case, the thought of an XIP kernel with an allmodconfig config > rather misses one of the fundamental problems with XIP multiplatform. I never said anything about running an XIP kernel with allmodconfig, or even an XIP kernel with more than one platform enabled. What I want is to be able to turn on XIP_KERNEL in a configuration that has exactly one machine enabled, but not requiring that machine to have a separate entry in the "ARM system type" choice statement. The fact that it allows one to also set silly configurations is unfortunate, but there are lots of silly configurations that one can enable today. > If you /ever/ want to write to the flash which the XIP kernel is contained, > you must move the interrupt handling code out into RAM, so that when an > interrupt happens, you can talk to the flash chip to make the kernel > readable again. That takes *all* of the initial interrupt handling code > and data into RAM. > > What that means is that our current IRQ multi-handler solution doesn't > work there - and we need a set of platform specific assembly fragments > to do this. This would be imply ARCH_MTD_XIP, which is currently not allowed for anything that is part of ARCH_MULTIPLATFORM, and this patch doesn't change that. If we ever want to allow it, I think you are right that it would require significant extra work for abstracting xip_irqpending, xip_currtime, xip_elapsed_since and xip_cpu_idle to build with more than one platform enabled. > As I said previously, there's also the complexity in setting up the XIP > mappings in the assembly code, which takes quite an amount of knowledge > of the physical memory layout on the SoC. > > Frankly, I think the idea of XIP and multiplatform is a pipedream. What about MMU-less systems then? The underlying problem is similar: when we converted ARCH_VEXPRESS to multiplatform, we lost the ability to run the Cortex-R4 tiles, or to run the ARMv7-A tiles with the MMU disabled, which apparently were either working out of the box, or required only a small set of patches on top. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 50762cc..14d0dce 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1091,7 +1091,7 @@ config ARM_ERRATA_430973 config ARM_ERRATA_458693 bool "ARM errata: Processor deadlock when a false hazard is created" depends on CPU_V7 - depends on !ARCH_MULTIPLATFORM + depends on !ARCH_MULTIPLATFORM_STRICT help This option enables the workaround for the 458693 Cortex-A8 (r2p0) erratum. For very specific sequences of memory operations, it is @@ -1105,7 +1105,7 @@ config ARM_ERRATA_458693 config ARM_ERRATA_460075 bool "ARM errata: Data written to the L2 cache can be overwritten with stale data" depends on CPU_V7 - depends on !ARCH_MULTIPLATFORM + depends on !ARCH_MULTIPLATFORM_STRICT help This option enables the workaround for the 460075 Cortex-A8 (r2p0) erratum. Any asynchronous access to the L2 cache may encounter a @@ -1118,7 +1118,7 @@ config ARM_ERRATA_460075 config ARM_ERRATA_742230 bool "ARM errata: DMB operation may be faulty" depends on CPU_V7 && SMP - depends on !ARCH_MULTIPLATFORM + depends on !ARCH_MULTIPLATFORM_STRICT help This option enables the workaround for the 742230 Cortex-A9 (r1p0..r2p2) erratum. Under rare circumstances, a DMB instruction @@ -1131,7 +1131,7 @@ config ARM_ERRATA_742230 config ARM_ERRATA_742231 bool "ARM errata: Incorrect hazard handling in the SCU may lead to data corruption" depends on CPU_V7 && SMP - depends on !ARCH_MULTIPLATFORM + depends on !ARCH_MULTIPLATFORM_STRICT help This option enables the workaround for the 742231 Cortex-A9 (r2p0..r2p2) erratum. Under certain conditions, specific to the @@ -1168,7 +1168,7 @@ config ARM_ERRATA_720789 config ARM_ERRATA_743622 bool "ARM errata: Faulty hazard checking in the Store Buffer may lead to data corruption" depends on CPU_V7 - depends on !ARCH_MULTIPLATFORM + depends on !ARCH_MULTIPLATFORM_STRICT help This option enables the workaround for the 743622 Cortex-A9 (r2p*) erratum. Under very rare conditions, a faulty @@ -1182,7 +1182,7 @@ config ARM_ERRATA_743622 config ARM_ERRATA_751472 bool "ARM errata: Interrupted ICIALLUIS may prevent completion of broadcasted operation" depends on CPU_V7 - depends on !ARCH_MULTIPLATFORM + depends on !ARCH_MULTIPLATFORM_STRICT help This option enables the workaround for the 751472 Cortex-A9 (prior to r3p0) erratum. An interrupted ICIALLUIS operation may prevent the @@ -1987,7 +1987,7 @@ endchoice config XIP_KERNEL bool "Kernel Execute-In-Place from ROM" - depends on !ARM_LPAE && !ARCH_MULTIPLATFORM + depends on !ARM_LPAE && !ARCH_MULTIPLATFORM_STRICT 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
With the ARCH_MULTIPLATFORM_STRICT option, it becomes much easier to enable the ERRATA options when we know at configuration time that we don't care about the generic case. The previous configuration makes XIP_KERNEL option fundamentally non-MULTIPLATFORM, but it's still valid to select it when building for !ARCH_MULTIPLATFORM_STRICT and selecting only the one machine that you want to run on. So allow ARM_ERRATA and XIP_KERNEL options to be enabled without ARCH_MULTIPLATFORM_STRICT. Signed-off-by: Xia Kaixu <kaixu.xia@linaro.org> --- arch/arm/Kconfig | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)