| Message ID | 1428090292-21693-8-git-send-email-stefan@agner.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Apr 03, 2015 at 09:44:48PM +0200, Stefan Agner wrote: > In order to support SoC with heterogenous CPU architectures (such > as Freescale Vybrid/i.MXSX) it is preferable to use the same > architecture (ARCH_MXC in this case) for the MMU enabled and !MMU > CPU. Hence allow to select MULTIPLATFORM even without MMU. > > Signed-off-by: Stefan Agner <stefan@agner.ch> > --- > arch/arm/Kconfig | 21 ++++++++++----------- > 1 file changed, 10 insertions(+), 11 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 9f1f09a..636cb3f 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -230,7 +230,7 @@ config VECTORS_BASE > in size. > > config ARM_PATCH_PHYS_VIRT > - bool "Patch physical to virtual translations at runtime" if EMBEDDED > + bool "Patch physical to virtual translations at runtime" if EMBEDDED || (ARCH_MULTIPLATFORM && MMU) > default y This makes no sense. Multiplatform MMU _requires_ this feature, so why offer it to the user when multiplatform is enabled _and_ MMU is enabled? Patch 7817/1 in the patch system tried doing something like you're trying to do here - I wonder whether you've reviewed the mailing list for previous discussions. Given that it's Easter, I'm not going to re-state what I said last time this came up, but instead leave you to do some research. For example, reading message id <20130819232411.GX23006@n2100.arm.linux.org.uk>... Thanks.
On 2015-04-03 22:09, Russell King - ARM Linux wrote: > On Fri, Apr 03, 2015 at 09:44:48PM +0200, Stefan Agner wrote: >> In order to support SoC with heterogenous CPU architectures (such >> as Freescale Vybrid/i.MXSX) it is preferable to use the same >> architecture (ARCH_MXC in this case) for the MMU enabled and !MMU >> CPU. Hence allow to select MULTIPLATFORM even without MMU. >> >> Signed-off-by: Stefan Agner <stefan@agner.ch> >> --- >> arch/arm/Kconfig | 21 ++++++++++----------- >> 1 file changed, 10 insertions(+), 11 deletions(-) >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index 9f1f09a..636cb3f 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -230,7 +230,7 @@ config VECTORS_BASE >> in size. >> >> config ARM_PATCH_PHYS_VIRT >> - bool "Patch physical to virtual translations at runtime" if EMBEDDED >> + bool "Patch physical to virtual translations at runtime" if EMBEDDED || (ARCH_MULTIPLATFORM && MMU) >> default y > > This makes no sense. Multiplatform MMU _requires_ this feature, so why > offer it to the user when multiplatform is enabled _and_ MMU is enabled? I see, this is plain wrong. Will replace that with a select ... if MMU in multiplatform. > Patch 7817/1 in the patch system tried doing something like you're trying > to do here - I wonder whether you've reviewed the mailing list for > previous discussions. I did some research at RFC/v1 time and mainly looked into Arnd's git trees. Most patches just open up !MMU for multiplatform. What I'm trying to do here is to enable !MMU with multiplatform while keeping the impact as little as possible, e.g. by making all other platforms in multiplatform dependent on MMU. See also https://www.marc.info/?l=linux-kernel&m=141997848124399&w=2 > Given that it's Easter, I'm not going to re-state what I said last time > this came up, but instead leave you to do some research. For example, > reading message id <20130819232411.GX23006@n2100.arm.linux.org.uk>... Also looked at some other messages about this topic, but I guess quotes from the message above will do to discuss this further: > Now, here's the question: can multiplatform ever work properly on nommu? > > We get multiplatform working on MMU by using the MMU to provide a more > consistent view of the system. On noMMU, we don't have that. So if > your kernel is built to run assuming that it will be located in ram at > location X on platform Y, that isn't going to work if platform Z doesn't > have RAM there. The platforms I primarily have in mind (heterogeneous multi-processing SoC's with MMU/!MMU processors) would actually allow such a multiplatform kernel: i.MX6 SoloX as well as Vybrid have the main memory in the same location, hence one could build a multiplatform !MMU kernel for this two devices. Of course, this is possible more by chance. I also did not tried it yet. I don't have a i.MX6 SoloX device. > My feeling is that the motivation behind this patch is to avoid an > amount of yuckyness associated with trying to enable Versatile Express > support outside of the multiplatform container - it's not really about > being able to build a single zImage which works on all noMMU platforms. > So, I don't think this is the right solution to this problem. I must admit that this was the main motivation for me too. My first approach was to create a set of completely independent config symbols: http://marc.info/?l=linux-arm-kernel&m=141756604900611&w=2 However, I'm sure this could be done better and with less config symbols. So, if you think it would be worth enabling multiplatform for these devices (Vybrid/i.MX6 SoloX), I would prepare a patchset which does it while not converting EFM32 to multiplatform (as patch 08/11 currently does). If you think it's also not worth for those devices, I will try to enable ARCH_MXC/SOC_VF610 with !MMU and !MULTIPLATFORM... -- Stefan
On Sat, Apr 04, 2015 at 01:56:20AM +0200, Stefan Agner wrote: > On 2015-04-03 22:09, Russell King - ARM Linux wrote: > > On Fri, Apr 03, 2015 at 09:44:48PM +0200, Stefan Agner wrote: > >> In order to support SoC with heterogenous CPU architectures (such > >> as Freescale Vybrid/i.MXSX) it is preferable to use the same > >> architecture (ARCH_MXC in this case) for the MMU enabled and !MMU > >> CPU. Hence allow to select MULTIPLATFORM even without MMU. > >> > >> Signed-off-by: Stefan Agner <stefan@agner.ch> > >> --- > >> arch/arm/Kconfig | 21 ++++++++++----------- > >> 1 file changed, 10 insertions(+), 11 deletions(-) > >> > >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > >> index 9f1f09a..636cb3f 100644 > >> --- a/arch/arm/Kconfig > >> +++ b/arch/arm/Kconfig > >> @@ -230,7 +230,7 @@ config VECTORS_BASE > >> in size. > >> > >> config ARM_PATCH_PHYS_VIRT > >> - bool "Patch physical to virtual translations at runtime" if EMBEDDED > >> + bool "Patch physical to virtual translations at runtime" if EMBEDDED || (ARCH_MULTIPLATFORM && MMU) > >> default y > > > > This makes no sense. Multiplatform MMU _requires_ this feature, so why > > offer it to the user when multiplatform is enabled _and_ MMU is enabled? > > I see, this is plain wrong. Will replace that with a select ... if MMU > in multiplatform. I think what I'd like to see is, in the top level choice: config ARM_SINGLE_ARMV7M bool "ARM architecture v7M compliant (Cortex-M0/M3/M4) SoC" depends on !MMU select ARM_NVIC ... etc ... which then allows a /multiplatform/ v7M kernel to be built, allowing the selection of EFM32, SOC_VF610, and any other v7M compliant SoC. So, it's very similar to multiplatform in the sense that several SoCs can be built together, but we preserve the need not to build incompatible stuff together. Thoughts?
On 2015-04-05 18:10, Russell King - ARM Linux wrote: > On Sat, Apr 04, 2015 at 01:56:20AM +0200, Stefan Agner wrote: >> On 2015-04-03 22:09, Russell King - ARM Linux wrote: >> > On Fri, Apr 03, 2015 at 09:44:48PM +0200, Stefan Agner wrote: >> >> In order to support SoC with heterogenous CPU architectures (such >> >> as Freescale Vybrid/i.MXSX) it is preferable to use the same >> >> architecture (ARCH_MXC in this case) for the MMU enabled and !MMU >> >> CPU. Hence allow to select MULTIPLATFORM even without MMU. >> >> >> >> Signed-off-by: Stefan Agner <stefan@agner.ch> >> >> --- >> >> arch/arm/Kconfig | 21 ++++++++++----------- >> >> 1 file changed, 10 insertions(+), 11 deletions(-) >> >> >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> >> index 9f1f09a..636cb3f 100644 >> >> --- a/arch/arm/Kconfig >> >> +++ b/arch/arm/Kconfig >> >> @@ -230,7 +230,7 @@ config VECTORS_BASE >> >> in size. >> >> >> >> config ARM_PATCH_PHYS_VIRT >> >> - bool "Patch physical to virtual translations at runtime" if EMBEDDED >> >> + bool "Patch physical to virtual translations at runtime" if EMBEDDED || (ARCH_MULTIPLATFORM && MMU) >> >> default y >> > >> > This makes no sense. Multiplatform MMU _requires_ this feature, so why >> > offer it to the user when multiplatform is enabled _and_ MMU is enabled? >> >> I see, this is plain wrong. Will replace that with a select ... if MMU >> in multiplatform. > > I think what I'd like to see is, in the top level choice: > > config ARM_SINGLE_ARMV7M > bool "ARM architecture v7M compliant (Cortex-M0/M3/M4) SoC" > depends on !MMU > select ARM_NVIC > ... etc ... I guess that would be ARCH_SINGLE_ARMV7M? > > which then allows a /multiplatform/ v7M kernel to be built, allowing the > selection of EFM32, SOC_VF610, and any other v7M compliant SoC. In my view, that wouldn't end up being much different than what that patchset is doing: With the introduction of ARCH_MULTI_V7M, we add something like a top level v7M compliant selection. Due to the !MMU dependencies of all other CPU families the family selection is minimal (when selecting !MMU): *** CPU Core family selection *** [*] ARMv7-M based platforms (Cortex-M) And since ARCH_MULTI_V7M is not part of ARCH_MULTI_V6_V7 or anything, the whole SoC selection contains only sensible SoC's without further changes (also within the i.MX family, currently only "Vybrid Family VF610 support" is selectable): [ ] MMU-based Paged Memory Management Support ARM system type (Allow multiple platforms to be selected) ---> Multiple platform selection ---> [*] Energy Micro efm32 [*] Freescale i.MX family ---> *** Processor Type *** ... > So, it's very similar to multiplatform in the sense that several SoCs > can be built together, but we preserve the need not to build > incompatible stuff together. As far as I can tell, this is already the case with that patchset. The differences boil down to on which level we split the v7M CPU selection apart: On ARCH_* level or ARCH_MULTI_* level. Given that we allow a multiplatform _v7M kernel, the latter sounds more natural to me... Are there arguments to split v7M CPU selection apart on ARCH_* level which I don't see? -- Stefan
On Mon, Apr 06, 2015 at 12:19:43AM +0200, Stefan Agner wrote: > On 2015-04-05 18:10, Russell King - ARM Linux wrote: > > config ARM_SINGLE_ARMV7M > > bool "ARM architecture v7M compliant (Cortex-M0/M3/M4) SoC" > > depends on !MMU > > select ARM_NVIC > > ... etc ... > > I guess that would be ARCH_SINGLE_ARMV7M? No, I meant ARM_SINGLE_xxx > > which then allows a /multiplatform/ v7M kernel to be built, allowing the > > selection of EFM32, SOC_VF610, and any other v7M compliant SoC. > > In my view, that wouldn't end up being much different than what that > patchset is doing: It's different. It's different because we are _not_ enabling multiplatform. Multiplatform brings with it all the MMU-full stuff that we don't want on !MMU. You're thinking far too specifically about V7M here. We have other !MMU CPUs, such as ARM946 and ARM940 which are older generation mmuless CPUs. The problem with the ARCH_MULTI_V7M approach is that they're V4T and V5 CPUs, and we _really_ don't want to enable ARCH_MULTI_V4T and ARCH_MULTI_V5. If we did that, we'll allow _every_ V4T and V5 multiplatform to be selected, whether they're compatible with nommu or not - and whether they're compatible with each other or not. So, that kind of solution _doesn't_ scale to what we _once_ already allowed. > As far as I can tell, this is already the case with that patchset. What I'm trying to do here is to fix the cockup that the multiplatform conversion has created with previous generation noMMU and restore it back to where it should be without excluding the newer stuff from it. What you're interested in is just the newer stuff. You're approaching the problem from a different angle and thinking that your solution is the best. I'm saying it has deficiencies.
On 2015-04-06 00:44, Russell King - ARM Linux wrote: > On Mon, Apr 06, 2015 at 12:19:43AM +0200, Stefan Agner wrote: >> On 2015-04-05 18:10, Russell King - ARM Linux wrote: >> > config ARM_SINGLE_ARMV7M >> > bool "ARM architecture v7M compliant (Cortex-M0/M3/M4) SoC" >> > depends on !MMU >> > select ARM_NVIC >> > ... etc ... >> >> I guess that would be ARCH_SINGLE_ARMV7M? > > No, I meant ARM_SINGLE_xxx > >> > which then allows a /multiplatform/ v7M kernel to be built, allowing the >> > selection of EFM32, SOC_VF610, and any other v7M compliant SoC. >> >> In my view, that wouldn't end up being much different than what that >> patchset is doing: > > It's different. It's different because we are _not_ enabling multiplatform. > Multiplatform brings with it all the MMU-full stuff that we don't want on > !MMU. You mean config symbols? There are 2-3 config symbols we don't want with ARCH_MULTI_V7M and we have to exclude. But there would be also a duplication of some already given by multiplatform when creating a new top level config symbol... > You're thinking far too specifically about V7M here. We have other !MMU > CPUs, such as ARM946 and ARM940 which are older generation mmuless CPUs. > > The problem with the ARCH_MULTI_V7M approach is that they're V4T and V5 > CPUs, and we _really_ don't want to enable ARCH_MULTI_V4T and > ARCH_MULTI_V5. If we did that, we'll allow _every_ V4T and V5 > multiplatform to be selected, whether they're compatible with nommu > or not - and whether they're compatible with each other or not. Just from a selection view, ARM946 and ARM940 would still _not_ be selectable because this change makes ARCH_MULTI_V4T/V5 being dependent on MMU. > > So, that kind of solution _doesn't_ scale to what we _once_ already > allowed. > >> As far as I can tell, this is already the case with that patchset. > > What I'm trying to do here is to fix the cockup that the multiplatform > conversion has created with previous generation noMMU and restore it > back to where it should be without excluding the newer stuff from it. Would be a partial revert (remove ARCH_MULTI_* from CPU_ARM940T and CPU_ARM946E) of dc680b989d51 ("ARM: fix multiplatform allmodcompile") be the right thing to do then? Given that ARCH_MULTI_V4T/V5 is MMU dependent, those CPU's will not be selected even when building the integrator multiplatform image... However, due to the selection limitations outlined above, this would only be cosmetic anyway. > What you're interested in is just the newer stuff. You're approaching > the problem from a different angle and thinking that your solution is > the best. I'm saying it has deficiencies. When keeping the old CPU's out of multiplatform game properly, what would speak against ARCH_MULTI_V7M? I still think if we allow a multiplatform v7M image, it is cleaner to align that to the MMU multiplatform stuff. Maybe I don't really get the grasp of ARM_SINGLE_ARMV7M. In my understanding it would be a new top level config symbol which kind of merges ARCH_MULTIPLATFORM and ARCH_MULTI_V7M. It is not my goal to enable !MMU on MULTIARCH per se. It's just that when enabling V7M with ARCH_MULTIPLATFORM, it makes it easier to enable the Cortex-M4 for the HMP platforms on those multiplatform only SoC's. When creating a new config symbol on a high level, this advantage is gone... I then could also create a top level ARCH_MXCV7M, which selects multiplatform only ARCH_MXC. -- Stefan
On Mon, Apr 06, 2015 at 01:50:17AM +0200, Stefan Agner wrote: > On 2015-04-06 00:44, Russell King - ARM Linux wrote: > > On Mon, Apr 06, 2015 at 12:19:43AM +0200, Stefan Agner wrote: > >> On 2015-04-05 18:10, Russell King - ARM Linux wrote: > >> > config ARM_SINGLE_ARMV7M > >> > bool "ARM architecture v7M compliant (Cortex-M0/M3/M4) SoC" > >> > depends on !MMU > >> > select ARM_NVIC > >> > ... etc ... > >> > >> I guess that would be ARCH_SINGLE_ARMV7M? > > > > No, I meant ARM_SINGLE_xxx > > > >> > which then allows a /multiplatform/ v7M kernel to be built, allowing the > >> > selection of EFM32, SOC_VF610, and any other v7M compliant SoC. > >> > >> In my view, that wouldn't end up being much different than what that > >> patchset is doing: > > > > It's different. It's different because we are _not_ enabling multiplatform. > > Multiplatform brings with it all the MMU-full stuff that we don't want on > > !MMU. > > You mean config symbols? There are 2-3 config symbols we don't want with > ARCH_MULTI_V7M and we have to exclude. But there would be also a > duplication of some already given by multiplatform when creating a new > top level config symbol... Let me repeat: enabling multiplatform with !MMU is wrong. It allows you to build totally incompatible machines together that will never boot. It will cause users headaches when they try to build for something only to find that they've got a bunch if incompatible other platforms or other symbols enabled too. Then they've got to work out how to disable those, and that's not easy with the abuse that "select" gets. > > You're thinking far too specifically about V7M here. We have other !MMU > > CPUs, such as ARM946 and ARM940 which are older generation mmuless CPUs. > > > > The problem with the ARCH_MULTI_V7M approach is that they're V4T and V5 > > CPUs, and we _really_ don't want to enable ARCH_MULTI_V4T and > > ARCH_MULTI_V5. If we did that, we'll allow _every_ V4T and V5 > > multiplatform to be selected, whether they're compatible with nommu > > or not - and whether they're compatible with each other or not. > > Just from a selection view, ARM946 and ARM940 would still _not_ be > selectable because this change makes ARCH_MULTI_V4T/V5 being dependent > on MMU. Thanks for telling me something I already know, and already have a patch to fix. > > So, that kind of solution _doesn't_ scale to what we _once_ already > > allowed. > > > >> As far as I can tell, this is already the case with that patchset. > > > > What I'm trying to do here is to fix the cockup that the multiplatform > > conversion has created with previous generation noMMU and restore it > > back to where it should be without excluding the newer stuff from it. > > Would be a partial revert (remove ARCH_MULTI_* from CPU_ARM940T and > CPU_ARM946E) of dc680b989d51 ("ARM: fix multiplatform allmodcompile") be > the right thing to do then? Given that ARCH_MULTI_V4T/V5 is MMU > dependent, those CPU's will not be selected even when building the > integrator multiplatform image... However, due to the selection > limitations outlined above, this would only be cosmetic anyway. You've identified the problem that I ran into... I already have this fixed, thanks. > > What you're interested in is just the newer stuff. You're approaching > > the problem from a different angle and thinking that your solution is > > the best. I'm saying it has deficiencies. > > When keeping the old CPU's out of multiplatform game properly, what > would speak against ARCH_MULTI_V7M? I still think if we allow a > multiplatform v7M image, it is cleaner to align that to the MMU > multiplatform stuff. > > Maybe I don't really get the grasp of ARM_SINGLE_ARMV7M. In my > understanding it would be a new top level config symbol which kind of > merges ARCH_MULTIPLATFORM and ARCH_MULTI_V7M. Exactly, but without the ability to select the other ARCH_MULTI_* symbols along with ARCH_MULTI_V7M. > It is not my goal to enable !MMU on MULTIARCH per se. It's just that > when enabling V7M with ARCH_MULTIPLATFORM, it makes it easier to enable > the Cortex-M4 for the HMP platforms on those multiplatform only SoC's. > When creating a new config symbol on a high level, this advantage is > gone... I then could also create a top level ARCH_MXCV7M, which selects > multiplatform only ARCH_MXC. No, you'd have a top level ARCH_SINGLE_ARMV7M. You would then be able to select the MXC V7M platforms along side any other V7M platform because the V7M platforms share the same basic memory layout. What you couldn't do is include _both_ support for Cortex-A9 and Cortex-M4 in one image - the two are incompatible because they have different physical address space layouts.
On 2015-04-06 10:15, Russell King - ARM Linux wrote: > On Mon, Apr 06, 2015 at 01:50:17AM +0200, Stefan Agner wrote: >> On 2015-04-06 00:44, Russell King - ARM Linux wrote: >> > On Mon, Apr 06, 2015 at 12:19:43AM +0200, Stefan Agner wrote: >> >> On 2015-04-05 18:10, Russell King - ARM Linux wrote: >> >> > config ARM_SINGLE_ARMV7M >> >> > bool "ARM architecture v7M compliant (Cortex-M0/M3/M4) SoC" >> >> > depends on !MMU >> >> > select ARM_NVIC >> >> > ... etc ... >> >> >> >> I guess that would be ARCH_SINGLE_ARMV7M? >> > >> > No, I meant ARM_SINGLE_xxx >> > >> >> > which then allows a /multiplatform/ v7M kernel to be built, allowing the >> >> > selection of EFM32, SOC_VF610, and any other v7M compliant SoC. >> >> >> >> In my view, that wouldn't end up being much different than what that >> >> patchset is doing: >> > >> > It's different. It's different because we are _not_ enabling multiplatform. >> > Multiplatform brings with it all the MMU-full stuff that we don't want on >> > !MMU. >> >> You mean config symbols? There are 2-3 config symbols we don't want with >> ARCH_MULTI_V7M and we have to exclude. But there would be also a >> duplication of some already given by multiplatform when creating a new >> top level config symbol... > > Let me repeat: enabling multiplatform with !MMU is wrong. It allows > you to build totally incompatible machines together that will never > boot. It will cause users headaches when they try to build for something > only to find that they've got a bunch if incompatible other platforms > or other symbols enabled too. Then they've got to work out how to > disable those, and that's not easy with the abuse that "select" gets. > >> > You're thinking far too specifically about V7M here. We have other !MMU >> > CPUs, such as ARM946 and ARM940 which are older generation mmuless CPUs. >> > >> > The problem with the ARCH_MULTI_V7M approach is that they're V4T and V5 >> > CPUs, and we _really_ don't want to enable ARCH_MULTI_V4T and >> > ARCH_MULTI_V5. If we did that, we'll allow _every_ V4T and V5 >> > multiplatform to be selected, whether they're compatible with nommu >> > or not - and whether they're compatible with each other or not. >> >> Just from a selection view, ARM946 and ARM940 would still _not_ be >> selectable because this change makes ARCH_MULTI_V4T/V5 being dependent >> on MMU. > > Thanks for telling me something I already know, and already have a patch > to fix. > >> > So, that kind of solution _doesn't_ scale to what we _once_ already >> > allowed. >> > >> >> As far as I can tell, this is already the case with that patchset. >> > >> > What I'm trying to do here is to fix the cockup that the multiplatform >> > conversion has created with previous generation noMMU and restore it >> > back to where it should be without excluding the newer stuff from it. >> >> Would be a partial revert (remove ARCH_MULTI_* from CPU_ARM940T and >> CPU_ARM946E) of dc680b989d51 ("ARM: fix multiplatform allmodcompile") be >> the right thing to do then? Given that ARCH_MULTI_V4T/V5 is MMU >> dependent, those CPU's will not be selected even when building the >> integrator multiplatform image... However, due to the selection >> limitations outlined above, this would only be cosmetic anyway. > > You've identified the problem that I ran into... I already have this > fixed, thanks. > >> > What you're interested in is just the newer stuff. You're approaching >> > the problem from a different angle and thinking that your solution is >> > the best. I'm saying it has deficiencies. >> >> When keeping the old CPU's out of multiplatform game properly, what >> would speak against ARCH_MULTI_V7M? I still think if we allow a >> multiplatform v7M image, it is cleaner to align that to the MMU >> multiplatform stuff. >> >> Maybe I don't really get the grasp of ARM_SINGLE_ARMV7M. In my >> understanding it would be a new top level config symbol which kind of >> merges ARCH_MULTIPLATFORM and ARCH_MULTI_V7M. > > Exactly, but without the ability to select the other ARCH_MULTI_* symbols > along with ARCH_MULTI_V7M. > >> It is not my goal to enable !MMU on MULTIARCH per se. It's just that >> when enabling V7M with ARCH_MULTIPLATFORM, it makes it easier to enable >> the Cortex-M4 for the HMP platforms on those multiplatform only SoC's. >> When creating a new config symbol on a high level, this advantage is >> gone... I then could also create a top level ARCH_MXCV7M, which selects >> multiplatform only ARCH_MXC. > > No, you'd have a top level ARCH_SINGLE_ARMV7M. You would then be > able to select the MXC V7M platforms along side any other V7M platform > because the V7M platforms share the same basic memory layout. > > What you couldn't do is include _both_ support for Cortex-A9 and > Cortex-M4 in one image - the two are incompatible because they have > different physical address space layouts. We already prevent a kernel image which mixes V4/V4T/V5 and V6/V7. And so we would do with V7M too. Just because it's in multiplatform doesn't mean we need to mix things up. -- Stefan
On Mon, Apr 06, 2015 at 10:38:10AM +0200, Stefan Agner wrote: > We already prevent a kernel image which mixes V4/V4T/V5 and V6/V7. And > so we would do with V7M too. Just because it's in multiplatform doesn't > mean we need to mix things up. I don't think you're getting what I'm saying at all... :( Please read the first bit of my replies again, where I say that we do _not_ want to remove the !MMU dependency from multiplatform. This is something I feel _very_ strongly about, and something which I've written about many times on this list.
On 2015-04-06 10:54, Russell King - ARM Linux wrote: > On Mon, Apr 06, 2015 at 10:38:10AM +0200, Stefan Agner wrote: >> We already prevent a kernel image which mixes V4/V4T/V5 and V6/V7. And >> so we would do with V7M too. Just because it's in multiplatform doesn't >> mean we need to mix things up. > > I don't think you're getting what I'm saying at all... :( It's not that I don't get it. I'm just arguing against it. IMHO, it's wrong to create a parallel universe for v7M multiplatform... Multiplatform as I understand it is mainly about selecting multiple SoC _platforms_ but not necessarily multiple CPU platforms. It happens to work well for V6/V7, but does not for others, and preventing multiselection for incompatible CPU platforms is the way to prevent creating such images. > Please read the first bit of my replies again, where I say that we do > _not_ want to remove the !MMU dependency from multiplatform. This is > something I feel _very_ strongly about, and something which I've written > about many times on this list. Ok, I don't have such a strong feel for multiplatform, it just feels a bit better to me. I need a top level ARCH which is able to live with !MMU. Will try the ARCH_SINGLE_ARMV7M approach then. -- Stefan
On Mon, Apr 06, 2015 at 11:33:53AM +0200, Stefan Agner wrote: > On 2015-04-06 10:54, Russell King - ARM Linux wrote: > > On Mon, Apr 06, 2015 at 10:38:10AM +0200, Stefan Agner wrote: > >> We already prevent a kernel image which mixes V4/V4T/V5 and V6/V7. And > >> so we would do with V7M too. Just because it's in multiplatform doesn't > >> mean we need to mix things up. > > > > I don't think you're getting what I'm saying at all... :( > > It's not that I don't get it. I'm just arguing against it. > > IMHO, it's wrong to create a parallel universe for v7M multiplatform... > > Multiplatform as I understand it is mainly about selecting multiple SoC > _platforms_ but not necessarily multiple CPU platforms. It happens to > work well for V6/V7, but does not for others, and preventing > multiselection for incompatible CPU platforms is the way to prevent > creating such images. Let's be clear: I'm _not_ arguing against being able to select multiple SoC platforms at all. I'm merely arguing about how it should be done. What I'm saying, is that MULTIPLATFORM itself does _not_ work for all noMMU platforms. Yes, it _may_ work for V7M, but it doesn't work for previous generation stuff - and that's confusing. Let's look at what needs to happen to make V7M work the way you're suggesting: * Add "depends on !MMU" to all the existing ARCH_MULTI_* symbols. * Append "if MMU" to the selection of ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR in multiplatform. We then have the problem for the older generation noMMU stuff. Should we stuff into the multiplatform architecture options for selecting the older generation noMMU _platforms_ into the "CPU Core family selection" menu? That's clearly wrong because they're not "CPU Cores". So, we have to find somewhere else to put the older generation stuff, and by doing so, that causes confusion, because we now have to select multiplatform for one group of noMMU implementations, and _not_ select it for another group of noMMU implementations. Imagine yourself writing up a document describing how to configure the kernel for all noMMU platforms which will be read by many people with varying degrees of English comprehension across the world, and how you would describe to them, such that they clearly understood, how to choose the right options.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 9f1f09a..636cb3f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -230,7 +230,7 @@ config VECTORS_BASE in size. config ARM_PATCH_PHYS_VIRT - bool "Patch physical to virtual translations at runtime" if EMBEDDED + bool "Patch physical to virtual translations at runtime" if EMBEDDED || (ARCH_MULTIPLATFORM && MMU) default y depends on !XIP_KERNEL && MMU depends on !ARCH_REALVIEW || !SPARSEMEM @@ -305,15 +305,12 @@ config MMU # choice prompt "ARM system type" - default ARCH_VERSATILE if !MMU - default ARCH_MULTIPLATFORM if MMU + default ARCH_MULTIPLATFORM config ARCH_MULTIPLATFORM bool "Allow multiple platforms to be selected" - depends on MMU select ARCH_WANT_OPTIONAL_GPIOLIB select ARM_HAS_SG_CHAIN - select ARM_PATCH_PHYS_VIRT select AUTO_ZRELADDR select CLKSRC_OF select COMMON_CLK @@ -785,13 +782,13 @@ comment "CPU Core family selection" config ARCH_MULTI_V4 bool "ARMv4 based platforms (FA526)" - depends on !ARCH_MULTI_V6_V7 + depends on !ARCH_MULTI_V6_V7 && MMU select ARCH_MULTI_V4_V5 select CPU_FA526 config ARCH_MULTI_V4T bool "ARMv4T based platforms (ARM720T, ARM920T, ...)" - depends on !ARCH_MULTI_V6_V7 + depends on !ARCH_MULTI_V6_V7 && MMU select ARCH_MULTI_V4_V5 select CPU_ARM920T if !(CPU_ARM7TDMI || CPU_ARM720T || \ CPU_ARM740T || CPU_ARM9TDMI || CPU_ARM922T || \ @@ -799,7 +796,7 @@ config ARCH_MULTI_V4T config ARCH_MULTI_V5 bool "ARMv5 based platforms (ARM926T, XSCALE, PJ1, ...)" - depends on !ARCH_MULTI_V6_V7 + depends on !ARCH_MULTI_V6_V7 && MMU select ARCH_MULTI_V4_V5 select CPU_ARM926T if !(CPU_ARM946E || CPU_ARM1020 || \ CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || \ @@ -810,11 +807,13 @@ config ARCH_MULTI_V4_V5 config ARCH_MULTI_V6 bool "ARMv6 based platforms (ARM11)" + depends on MMU select ARCH_MULTI_V6_V7 select CPU_V6K config ARCH_MULTI_V7 - bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)" + bool "ARMv7-A based platforms (Cortex-A, PJ4, Scorpion, Krait)" + depends on MMU default y select ARCH_MULTI_V6_V7 select CPU_V7 @@ -825,7 +824,7 @@ config ARCH_MULTI_V6_V7 select MIGHT_HAVE_CACHE_L2X0 config ARCH_MULTI_CPU_AUTO - def_bool !(ARCH_MULTI_V4 || ARCH_MULTI_V4T || ARCH_MULTI_V6_V7) + def_bool !(ARCH_MULTI_V4 || ARCH_MULTI_V4T || ARCH_MULTI_V6_V7) && MMU select ARCH_MULTI_V5 endmenu @@ -1967,7 +1966,7 @@ endchoice config XIP_KERNEL bool "Kernel Execute-In-Place from ROM" - depends on !ARM_LPAE && !ARCH_MULTIPLATFORM + depends on !ARM_LPAE && (!ARCH_MULTIPLATFORM || ARCH_MULTI_V7M) 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
In order to support SoC with heterogenous CPU architectures (such as Freescale Vybrid/i.MXSX) it is preferable to use the same architecture (ARCH_MXC in this case) for the MMU enabled and !MMU CPU. Hence allow to select MULTIPLATFORM even without MMU. Signed-off-by: Stefan Agner <stefan@agner.ch> --- arch/arm/Kconfig | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-)