[PATCH 0/3] v7-M support using MULTIPLATFORM

[PATCH 0/3] v7-M support using MULTIPLATFORM

[Uwe Kleine-König]

Hello,

this series makes it possible to benefit from the MULTIPLATFORM stuff
also for my v7-M machine (that is not yet supported in mainline).

Best regards
Uwe

Uwe Kleine-K?nig (3):
  ARM: drop !ARCH_MULTIPLATFORM dependency of XIP_KERNEL
  ARM: allow MULTIPLATFORM on no-MMU machines
  [RFC] ARM: prepare ARMv7-M for MULTIPLATFORM use

 arch/arm/Kconfig            | 16 ++++++++++------
 arch/arm/kernel/entry-v7m.S |  6 ++++--
 2 files changed, 14 insertions(+), 8 deletions(-)

-- 
1.8.4.rc3

[PATCH 1/3] ARM: drop !ARCH_MULTIPLATFORM dependency of XIP_KERNEL

[Uwe Kleine-König]

Enabling XIP_KERNEL requires specifying the physical address of the readonly
memory. As these addresses vary among different SoCs and even machines with
the same SoC enabling XIP_KERNEL might restrict the set of machines that can
run the resulting kernel to a subset of the configured in machines.

Still allowing XIP_KERNEL for a MULTIPLATFORM kernel makes sense as for some
platforms MULTIPLATFORM is mandatory (e.g. bcm, highbank or imx). So to
allow compiling a XIP kernel for these platforms, allow selecting XIP in the
presence of ARCH_MULTIPLATFORM.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
This patch might be problematic for compile coverage testing according to
Arnd. Still I need XIP for my efm32 machine as it only features 4 MiB of
RAM.
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 22efc5d..0f63a70 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2092,7 +2092,7 @@ endchoice
 
 config XIP_KERNEL
 	bool "Kernel Execute-In-Place from ROM"
-	depends on !ZBOOT_ROM && !ARM_LPAE && !ARCH_MULTIPLATFORM
+	depends on !ZBOOT_ROM && !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
-- 
1.8.4.rc3

[PATCH 2/3] ARM: allow MULTIPLATFORM on no-MMU machines

[Uwe Kleine-König]

There is no technical reason to not use the benefits of MULTIPLATFORM on a
no-MMU machine and my not-yet-mainline efm32 port does work just fine with
it. So drop the dependency.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0f63a70..d873a34 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -296,8 +296,7 @@ choice
 
 config ARCH_MULTIPLATFORM
 	bool "Allow multiple platforms to be selected"
-	depends on MMU
-	select ARM_PATCH_PHYS_VIRT
+	select ARM_PATCH_PHYS_VIRT if MMU && !XIP_KERNEL
 	select AUTO_ZRELADDR
 	select COMMON_CLK
 	select MULTI_IRQ_HANDLER
-- 
1.8.4.rc3

[PATCH 2/3] ARM: allow MULTIPLATFORM on no-MMU machines

[Jonathan Austin]

On 30/09/13 10:49, Uwe Kleine-K?nig wrote:
> There is no technical reason to not use the benefits of MULTIPLATFORM on a
> no-MMU machine and my not-yet-mainline efm32 port does work just fine with
> it. So drop the dependency.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> ---
>   arch/arm/Kconfig | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 0f63a70..d873a34 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -296,8 +296,7 @@ choice
>
>   config ARCH_MULTIPLATFORM
>   	bool "Allow multiple platforms to be selected"
> -	depends on MMU
> -	select ARM_PATCH_PHYS_VIRT
> +	select ARM_PATCH_PHYS_VIRT if MMU && !XIP_KERNEL
>   	select AUTO_ZRELADDR
>   	select COMMON_CLK
>   	select MULTI_IRQ_HANDLER
>


A patch much like this has been submitted in the past by Arnd and me, 
and Russell wasn't too happy with the idea because ARCH_MULTIPLATFORM 
doesn't really make sense for !MMU.

However, back then we were talking R/A class. For M-class the memory map 
is more clearly mandated, the idea of V7M platforms that are 
ARCH_MULTIPLATFORM compatible is much more feasible. One of the big 
issues for !MMU/ARCH_MULTIPLATFORM in the past was the need to select 
the vector configuration at build time - not something we need to worry 
about with V7M (where we have a configurable vector base), so from that 
point of view, this change makes sense.

But I'm not sure about the XIP_KERNEL part. Once you're using XIP_KERNEL 
again, multi-platform doesn't make much sense. Uwe, can you correct me 
on that?

Jonny

[PATCH 3/3] [RFC] ARM: prepare ARMv7-M for MULTIPLATFORM use

[Uwe Kleine-König]

v7-M is a third group that is incompatible with both v4/v5 and v6/v7.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
This behaves strange but I think is robust not to allow broken configs:

When v4/v5 is selected, v6/v7 and v7m are available for enabling, too.
When v6/v7 is selected the other choices are disabled
When v7m is selected only v6/v7 are available for enabling.
---
 arch/arm/Kconfig            | 11 ++++++++---
 arch/arm/kernel/entry-v7m.S |  6 ++++--
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d873a34..4d749fa 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -881,7 +881,7 @@ comment "CPU Core family selection"
 
 config ARCH_MULTI_V4T
 	bool "ARMv4T based platforms (ARM720T, ARM920T, ...)"
-	depends on !ARCH_MULTI_V6_V7
+	depends on !ARCH_MULTI_V6_V7 && !ARCH_MULTI_V7M
 	select ARCH_MULTI_V4_V5
 	select CPU_ARM920T if !(CPU_ARM7TDMI || CPU_ARM720T || \
 		CPU_ARM740T || CPU_ARM9TDMI || CPU_ARM922T || \
@@ -889,7 +889,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 && !ARCH_MULTI_V7M
 	select ARCH_MULTI_V4_V5
 	select CPU_ARM926T if (!CPU_ARM946E || CPU_ARM1020 || \
 		CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || \
@@ -912,8 +912,13 @@ config ARCH_MULTI_V7
 config ARCH_MULTI_V6_V7
 	bool
 
+config ARCH_MULTI_V7M
+	bool "ARMv7-M based platforms (Cortex-M)"
+	depends on !ARCH_MULTI_V6_V7 && !MMU
+	select CPU_V7M
+
 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 || ARCH_MULTI_V7M)
 	select ARCH_MULTI_V5
 
 endmenu
diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
index 52b2643..f72ced6 100644
--- a/arch/arm/kernel/entry-v7m.S
+++ b/arch/arm/kernel/entry-v7m.S
@@ -14,8 +14,6 @@
 #include <asm/thread_notify.h>
 #include <asm/v7m.h>
 
-#include <mach/entry-macro.S>
-
 #include "entry-header.S"
 
 #ifdef CONFIG_TRACE_IRQFLAGS
@@ -141,3 +139,7 @@ ENTRY(vector_table)
 	.rept	64 - 16
 	.long	__irq_entry		@ 16..64 - External Interrupts
 	.endr
+
+	.globl  handle_arch_irq
+handle_arch_irq:
+	.long	0
-- 
1.8.4.rc3

[PATCH 3/3] [RFC] ARM: prepare ARMv7-M for MULTIPLATFORM use

[Arnd Bergmann]

On Monday 30 September 2013, Uwe Kleine-K?nig wrote:
> v7-M is a third group that is incompatible with both v4/v5 and v6/v7.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> ---
> This behaves strange but I think is robust not to allow broken configs:
> 
> When v4/v5 is selected, v6/v7 and v7m are available for enabling, too.
> When v6/v7 is selected the other choices are disabled
> When v7m is selected only v6/v7 are available for enabling.

The Kconfig stuff all looks good, 

Acked-by: Arnd Bergmann <arnd@arndb.de>


> diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
> index 52b2643..f72ced6 100644
> --- a/arch/arm/kernel/entry-v7m.S
> +++ b/arch/arm/kernel/entry-v7m.S
> @@ -14,8 +14,6 @@
>  #include <asm/thread_notify.h>
>  #include <asm/v7m.h>
>  
> -#include <mach/entry-macro.S>
> -
>  #include "entry-header.S"
>  
>  #ifdef CONFIG_TRACE_IRQFLAGS
> @@ -141,3 +139,7 @@ ENTRY(vector_table)
>  	.rept	64 - 16
>  	.long	__irq_entry		@ 16..64 - External Interrupts
>  	.endr
> +
> +	.globl  handle_arch_irq
> +handle_arch_irq:
> +	.long	0
> -- 
> 1.8.4.rc3

I'm not sure about this part. I guess you should either make it
a separate patch, or describe what it's for in the patch description above.

Also, I'd put all of the text you have in the comment into the actual
changeset text, above the --- line, as others might find that useful
later.

	Arnd

[PATCH 3/3] [RFC] ARM: prepare ARMv7-M for MULTIPLATFORM use

[Uwe Kleine-König]

Hello Arnd,

On Mon, Sep 30, 2013 at 12:34:25PM +0200, Arnd Bergmann wrote:
> On Monday 30 September 2013, Uwe Kleine-K?nig wrote:
> > v7-M is a third group that is incompatible with both v4/v5 and v6/v7.
> > 
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > ---
> > This behaves strange but I think is robust not to allow broken configs:
> > 
> > When v4/v5 is selected, v6/v7 and v7m are available for enabling, too.
> > When v6/v7 is selected the other choices are disabled
> > When v7m is selected only v6/v7 are available for enabling.
> 
> The Kconfig stuff all looks good, 
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Thanks

> > @@ -141,3 +139,7 @@ ENTRY(vector_table)
> >  	.rept	64 - 16
> >  	.long	__irq_entry		@ 16..64 - External Interrupts
> >  	.endr
> > +
> > +	.globl  handle_arch_irq
> > +handle_arch_irq:
> > +	.long	0
> > -- 
> > 1.8.4.rc3
> 
> I'm not sure about this part. I guess you should either make it
> a separate patch, or describe what it's for in the patch description above.
This is needed because ARCH_MULTIPLATFORM selects MULTI_IRQ_HANDLER
which v7-M didn't use up to now. I will wait for a while for more
feedback then respin with a better changelog.
 
> Also, I'd put all of the text you have in the comment into the actual
> changeset text, above the --- line, as others might find that useful
> later.
ok

Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 3/3] [RFC] ARM: prepare ARMv7-M for MULTIPLATFORM use

[Uwe Kleine-König]

On Mon, Sep 30, 2013 at 12:34:25PM +0200, Arnd Bergmann wrote:
> On Monday 30 September 2013, Uwe Kleine-K?nig wrote:
> > v7-M is a third group that is incompatible with both v4/v5 and v6/v7.
> > 
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > ---
> > This behaves strange but I think is robust not to allow broken configs:
> > 
> > When v4/v5 is selected, v6/v7 and v7m are available for enabling, too.
> > When v6/v7 is selected the other choices are disabled
> > When v7m is selected only v6/v7 are available for enabling.
> 
> The Kconfig stuff all looks good, 
Actually this is a choice implemented using normal configs. Why not a
using a choice here:

choice
	prompt "CPU Core family selection"

config ARCH_MULTI_V4_V5
	bool "..."

config ARCH_MULTI_V6_V7
	bool "..."

config ARCH_MULTI_V7M
	bool "..."

endchoice

config ARCH_MULTI_V4T
	bool "ARMv4T based platforms (ARM720T, ARM920T, ...)"
	depends on ARCH_MULTI_V4_V5

config ARCH_MULTI_V5
	bool "ARMv5 based platforms (ARM926T, XSCALE, PJ1, ...)" if ARCH_MULTI_V4T
	depends on ARCH_MULTI_V4_V5
	default y if !ARCH_MULTI_V4T

config ARCH_MULTI_V6
	...

config ARCH_MULTI_V7
	...

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 0/3] v7-M support using MULTIPLATFORM

[Russell King - ARM Linux]

On Mon, Sep 30, 2013 at 11:49:34AM +0200, Uwe Kleine-K?nig wrote:
> Hello,
> 
> this series makes it possible to benefit from the MULTIPLATFORM stuff
> also for my v7-M machine (that is not yet supported in mainline).

The big problem I have with this is that the single zImage project is
forcing itself onto stuff like the small embedded stuff where it's not
appropriate for it to be.

Much of the multiplatform infrastructure relies on the ability to do
tricks with the MMU - placing various peripherals at known virtual
addresses.  Such tricks don't work on no-MMU platforms.

NoMMU platforms are inherently much more restricted and specialised,
and having multiplatform on them just doesn't make sense.  Yes, it
may give you the ability to increase compilation coverage, but will
the resulting image even work on the platform you're trying to target,
or will one of the other multi-platforms take over some settings and
screw it for you - like the link address.

XIP kernel is inherently limited to a single class of platforms.
Think about it - it's a very specialised.  XIP kernel needs several
things - it needs the kernel built in a special way such that the
data segment is separate from the text segment.  It needs to map the
flash memory storing the kernel code separately from the SDRAM.
It needs to know where the IRQ controller is and how to access it
to check for pending interrupts.

None of that is provided by the majority of multiplatform.

So, enabling the multiplatform Kconfig on such specialist platforms is
just opening up a huge can of worms.  Why anyone thinks this is a good
idea is way beyond me.

Also think about the argument you're making.  You need XIP kernel
because you have limited RAM, but you're willing to enable multiplatform
support which will allow you to build a kernel much larger than is
necessary for your platform by including other platforms in it.  Sorry,
that's just stupid.

So no.  If multiplatform gets in the way on noMMU platforms, then
multiplatform has ended up being done wrongly, and its multiplatform
that needs to be fixed.

[PATCH 0/3] v7-M support using MULTIPLATFORM

[Uwe Kleine-König]

Hello Russell,

On Thu, Oct 03, 2013 at 11:00:38PM +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 30, 2013 at 11:49:34AM +0200, Uwe Kleine-K?nig wrote:
> > Hello,
> > 
> > this series makes it possible to benefit from the MULTIPLATFORM stuff
> > also for my v7-M machine (that is not yet supported in mainline).
> 
> The big problem I have with this is that the single zImage project is
> forcing itself onto stuff like the small embedded stuff where it's not
> appropriate for it to be.
> 
> Much of the multiplatform infrastructure relies on the ability to do
> tricks with the MMU - placing various peripherals at known virtual
> addresses.  Such tricks don't work on no-MMU platforms.
Actually it's not for the multi-platform ability itself I selected it
for, but to benefit from other stuff that is currently only available
for it, i.e. I don't need a Makefile.boot, I don't need some mach/
headers.
 
> NoMMU platforms are inherently much more restricted and specialised,
> and having multiplatform on them just doesn't make sense.  Yes, it
> may give you the ability to increase compilation coverage, but will
> the resulting image even work on the platform you're trying to target,
> or will one of the other multi-platforms take over some settings and
> screw it for you - like the link address.
Well, the way things are suggested in my patches you can only select
other v7m machines alongside the efm32 platform. The bets are much
better there not to screw it for me. But of course I cannot proof this
as there is only one Cortex-M3 type supported in my tree.
 
> XIP kernel is inherently limited to a single class of platforms.
> Think about it - it's a very specialised.  XIP kernel needs several
> things - it needs the kernel built in a special way such that the
> data segment is separate from the text segment.  It needs to map the
> flash memory storing the kernel code separately from the SDRAM.
Right, but do we agree that it should be possible to create an XIP image
for i.MX6? If so: You currently cannot, because i.MX6 isn't configurable
without MULTIPLATFORM. Also in the times before MULTIPLATFORM XIP was
special. Already back than you could create a kernel for 2 (or more)
different machines (sharing the same SoC family) with XIP enabled. That
didn't necessarily made it work on both machines, maybe only one of them
had NOR flash.

So maybe the only problem is that the symbol is misnamed or at least
gives expectations that are not necessarily true. So you can configure a
MULTIPLATFORM kernel for a single machine only just fine.

> It needs to know where the IRQ controller is and how to access it
> to check for pending interrupts.
I didn't configure that, maybe this is only needed for writing to the
flash holding the XIP image?

> None of that is provided by the majority of multiplatform.
> 
> So, enabling the multiplatform Kconfig on such specialist platforms is
> just opening up a huge can of worms.  Why anyone thinks this is a good
> idea is way beyond me.
> 
> Also think about the argument you're making.  You need XIP kernel
> because you have limited RAM, but you're willing to enable multiplatform
> support which will allow you to build a kernel much larger than is
> necessary for your platform by including other platforms in it.  Sorry,
> that's just stupid.
Right, it will allow me to build a much bigger kernel (but I don't need
to). And it allows me a few more things (yes please).

Note I'm not 100% convinced that multiplatform is a sane idea for v7-M,
but still I see some advantages so I wouldn't call it stupid.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 0/3] v7-M support using MULTIPLATFORM

[Russell King - ARM Linux]

On Fri, Oct 04, 2013 at 12:28:01AM +0200, Uwe Kleine-K?nig wrote:
> Hello Russell,
> 
> On Thu, Oct 03, 2013 at 11:00:38PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Sep 30, 2013 at 11:49:34AM +0200, Uwe Kleine-K?nig wrote:
> > > Hello,
> > > 
> > > this series makes it possible to benefit from the MULTIPLATFORM stuff
> > > also for my v7-M machine (that is not yet supported in mainline).
> > 
> > The big problem I have with this is that the single zImage project is
> > forcing itself onto stuff like the small embedded stuff where it's not
> > appropriate for it to be.
> > 
> > Much of the multiplatform infrastructure relies on the ability to do
> > tricks with the MMU - placing various peripherals at known virtual
> > addresses.  Such tricks don't work on no-MMU platforms.
>
> Actually it's not for the multi-platform ability itself I selected it
> for, but to benefit from other stuff that is currently only available
> for it, i.e. I don't need a Makefile.boot, I don't need some mach/
> headers.

The only include file which MULTIPLATFORM itself hides is mach/timex.h -
the others are all optional wrt their individual NEED_xxx_H configs.
We should probably convert mach/timex.h to the NEED_xxx_H style as well.

As for not needing Makefile.boot, I guess we should allow the 'Image'
target to work if there's no Makefile.boot but disable the rest.

> > NoMMU platforms are inherently much more restricted and specialised,
> > and having multiplatform on them just doesn't make sense.  Yes, it
> > may give you the ability to increase compilation coverage, but will
> > the resulting image even work on the platform you're trying to target,
> > or will one of the other multi-platforms take over some settings and
> > screw it for you - like the link address.
> Well, the way things are suggested in my patches you can only select
> other v7m machines alongside the efm32 platform. The bets are much
> better there not to screw it for me. But of course I cannot proof this
> as there is only one Cortex-M3 type supported in my tree.

Hmm.  So, is it possible to build for the EFM32 platform and a SAM3N
in the same kernel?  The SAM3N devices are Cortex-M3 CPUs, with major
regions defined as flash in the bottom .5G, SRAM, external SRAM at
0x60000000, private peripherals at 0xe0000000, which is where the
system control block, system timer, nvic and so forth are located.

> Right, but do we agree that it should be possible to create an XIP image
> for i.MX6? If so: You currently cannot, because i.MX6 isn't configurable
> without MULTIPLATFORM. Also in the times before MULTIPLATFORM XIP was
> special.

That's one of the consequences of pushing to multiplatform support - XIP
has fallen by the way side as a result of this effort (it was discussed
previously) and we had decided that almost no one uses it anymore and it
would not be part of the multiplatform stuff.  It was only really used
by very few SA11x0 and PXA platforms anyway.

> Already back than you could create a kernel for 2 (or more)
> different machines (sharing the same SoC family) with XIP enabled. That
> didn't necessarily made it work on both machines, maybe only one of them
> had NOR flash.

That's quite a different issue from enabling MULTIPLATFORM and then
having a whole raft of completely different SoCs be configurable.
For any one SoC, it will work if you program the kernel into memory
starting at XIP_PHYS_ADDR.  The majority of platforms in any one SoC
group will have memory available at a fixed location.  For example,
on SA11x0, you can almost guarantee that there's some kind of flash
memory in flash bank 0, because that's how the system boots.  Same
for PXA.

> > It needs to know where the IRQ controller is and how to access it
> > to check for pending interrupts.
> I didn't configure that, maybe this is only needed for writing to the
> flash holding the XIP image?

Correct, which makes the flash effectively ROM.

> > None of that is provided by the majority of multiplatform.
> > 
> > So, enabling the multiplatform Kconfig on such specialist platforms is
> > just opening up a huge can of worms.  Why anyone thinks this is a good
> > idea is way beyond me.
> > 
> > Also think about the argument you're making.  You need XIP kernel
> > because you have limited RAM, but you're willing to enable multiplatform
> > support which will allow you to build a kernel much larger than is
> > necessary for your platform by including other platforms in it.  Sorry,
> > that's just stupid.
> 
> Right, it will allow me to build a much bigger kernel (but I don't need
> to). And it allows me a few more things (yes please).

"a few more things" - I count two things which you've mentioned so far,
both of which can be sorted out.  Anything else?

[PATCH 0/3] v7-M support using MULTIPLATFORM

[Nicolas Pitre]

On Fri, 4 Oct 2013, Russell King - ARM Linux wrote:

> On Fri, Oct 04, 2013 at 12:28:01AM +0200, Uwe Kleine-K?nig wrote:
> > Right, but do we agree that it should be possible to create an XIP image
> > for i.MX6? If so: You currently cannot, because i.MX6 isn't configurable
> > without MULTIPLATFORM. Also in the times before MULTIPLATFORM XIP was
> > special.
> 
> That's one of the consequences of pushing to multiplatform support - XIP
> has fallen by the way side as a result of this effort (it was discussed
> previously) and we had decided that almost no one uses it anymore and it
> would not be part of the multiplatform stuff.  It was only really used
> by very few SA11x0 and PXA platforms anyway.

Semantically, MULTIPLATFORM is incompatible with XIP as well as NOMMU.

So if a platform exists only when MULTIPLATFORM is selected, preventing 
it from being configured as NOMMU or XIP then something is broken with 
MULTIPLATFORM.


Nicolas

[PATCH 0/3] v7-M support using MULTIPLATFORM

[Uwe Kleine-König]

Hello Nicolas,

On Thu, Oct 03, 2013 at 09:46:42PM -0400, Nicolas Pitre wrote:
> On Fri, 4 Oct 2013, Russell King - ARM Linux wrote:
> 
> > On Fri, Oct 04, 2013 at 12:28:01AM +0200, Uwe Kleine-K?nig wrote:
> > > Right, but do we agree that it should be possible to create an XIP image
> > > for i.MX6? If so: You currently cannot, because i.MX6 isn't configurable
> > > without MULTIPLATFORM. Also in the times before MULTIPLATFORM XIP was
> > > special.
> > 
> > That's one of the consequences of pushing to multiplatform support - XIP
> > has fallen by the way side as a result of this effort (it was discussed
> > previously) and we had decided that almost no one uses it anymore and it
> > would not be part of the multiplatform stuff.  It was only really used
> > by very few SA11x0 and PXA platforms anyway.
> 
> Semantically, MULTIPLATFORM is incompatible with XIP as well as NOMMU.
> 
> So if a platform exists only when MULTIPLATFORM is selected, preventing 
> it from being configured as NOMMU or XIP then something is broken with 
> MULTIPLATFORM.
Is this an Ack for patch 1 in this series?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 0/3] v7-M support using MULTIPLATFORM

[Arnd Bergmann]

On Monday 04 November 2013, Uwe Kleine-K?nig wrote:
> Hello Nicolas,
> 
> On Thu, Oct 03, 2013 at 09:46:42PM -0400, Nicolas Pitre wrote:
> > On Fri, 4 Oct 2013, Russell King - ARM Linux wrote:
> > 
> > > On Fri, Oct 04, 2013 at 12:28:01AM +0200, Uwe Kleine-K?nig wrote:
> > > > Right, but do we agree that it should be possible to create an XIP image
> > > > for i.MX6? If so: You currently cannot, because i.MX6 isn't configurable
> > > > without MULTIPLATFORM. Also in the times before MULTIPLATFORM XIP was
> > > > special.
> > > 
> > > That's one of the consequences of pushing to multiplatform support - XIP
> > > has fallen by the way side as a result of this effort (it was discussed
> > > previously) and we had decided that almost no one uses it anymore and it
> > > would not be part of the multiplatform stuff.  It was only really used
> > > by very few SA11x0 and PXA platforms anyway.
> > 
> > Semantically, MULTIPLATFORM is incompatible with XIP as well as NOMMU.
> > 
> > So if a platform exists only when MULTIPLATFORM is selected, preventing 
> > it from being configured as NOMMU or XIP then something is broken with 
> > MULTIPLATFORM.
> Is this an Ack for patch 1 in this series?

Uwe, have you seen that patch that Jonathan Austin was working on to reorganize
the platform selection for multiplatform? I don't know if he has gotten around
the time to post it on the mailing list, if not he can probably follow up here.

	Arnd

[PATCH 0/3] v7-M support using MULTIPLATFORM

[Uwe Kleine-König]

Hi Russell,

On Fri, Oct 04, 2013 at 12:05:35AM +0100, Russell King - ARM Linux wrote:
> On Fri, Oct 04, 2013 at 12:28:01AM +0200, Uwe Kleine-K?nig wrote:
> > On Thu, Oct 03, 2013 at 11:00:38PM +0100, Russell King - ARM Linux wrote:
> > > On Mon, Sep 30, 2013 at 11:49:34AM +0200, Uwe Kleine-K?nig wrote:
> > > > Hello,
> > > > 
> > > > this series makes it possible to benefit from the MULTIPLATFORM stuff
> > > > also for my v7-M machine (that is not yet supported in mainline).
> > > 
> > > The big problem I have with this is that the single zImage project is
> > > forcing itself onto stuff like the small embedded stuff where it's not
> > > appropriate for it to be.
> > > 
> > > Much of the multiplatform infrastructure relies on the ability to do
> > > tricks with the MMU - placing various peripherals at known virtual
> > > addresses.  Such tricks don't work on no-MMU platforms.
> >
> > Actually it's not for the multi-platform ability itself I selected it
> > for, but to benefit from other stuff that is currently only available
> > for it, i.e. I don't need a Makefile.boot, I don't need some mach/
> > headers.
> 
> The only include file which MULTIPLATFORM itself hides is mach/timex.h -
> the others are all optional wrt their individual NEED_xxx_H configs.
> We should probably convert mach/timex.h to the NEED_xxx_H style as well.
> 
> As for not needing Makefile.boot, I guess we should allow the 'Image'
> target to work if there's no Makefile.boot but disable the rest.
Both suggestions sound fine for me.
 
> > > NoMMU platforms are inherently much more restricted and specialised,
> > > and having multiplatform on them just doesn't make sense.  Yes, it
> > > may give you the ability to increase compilation coverage, but will
> > > the resulting image even work on the platform you're trying to target,
> > > or will one of the other multi-platforms take over some settings and
> > > screw it for you - like the link address.
> > Well, the way things are suggested in my patches you can only select
> > other v7m machines alongside the efm32 platform. The bets are much
> > better there not to screw it for me. But of course I cannot proof this
> > as there is only one Cortex-M3 type supported in my tree.
> 
> Hmm.  So, is it possible to build for the EFM32 platform and a SAM3N
> in the same kernel?  The SAM3N devices are Cortex-M3 CPUs, with major
> regions defined as flash in the bottom .5G, SRAM, external SRAM at
> 0x60000000, private peripherals at 0xe0000000, which is where the
> system control block, system timer, nvic and so forth are located.
The block at 0xe0000000 is architecturally defined. Also flash at the
bottom is quite usual I think. All M3 and M4 use the nvic as irq
controller at a fixed address. So multi-arch on v7-M isn't as hard as it
could be.

> > Right, but do we agree that it should be possible to create an XIP image
> > for i.MX6? If so: You currently cannot, because i.MX6 isn't configurable
> > without MULTIPLATFORM. Also in the times before MULTIPLATFORM XIP was
> > special.
> 
> That's one of the consequences of pushing to multiplatform support - XIP
> has fallen by the way side as a result of this effort (it was discussed
> previously) and we had decided that almost no one uses it anymore and it
> would not be part of the multiplatform stuff.  It was only really used
> by very few SA11x0 and PXA platforms anyway.
I assume that new machines using efm32 (or any other M3) that are
targeted to run Linux will have bigger RAMs and so the XIP part will
matter less here.

> > Already back than you could create a kernel for 2 (or more)
> > different machines (sharing the same SoC family) with XIP enabled. That
> > didn't necessarily made it work on both machines, maybe only one of them
> > had NOR flash.
> 
> That's quite a different issue from enabling MULTIPLATFORM and then
> having a whole raft of completely different SoCs be configurable.
> For any one SoC, it will work if you program the kernel into memory
> starting at XIP_PHYS_ADDR.  The majority of platforms in any one SoC
> group will have memory available at a fixed location.  For example,
> on SA11x0, you can almost guarantee that there's some kind of flash
> memory in flash bank 0, because that's how the system boots.  Same
> for PXA.
In my eyes that's a poor excuse to drop XIP. Yes, it doesn't make sense
in all configurations, but in some it does. So IMHO better allow it in
all configurations than in none.
 
> > > None of that is provided by the majority of multiplatform.
> > > 
> > > So, enabling the multiplatform Kconfig on such specialist platforms is
> > > just opening up a huge can of worms.  Why anyone thinks this is a good
> > > idea is way beyond me.
> > > 
> > > Also think about the argument you're making.  You need XIP kernel
> > > because you have limited RAM, but you're willing to enable multiplatform
> > > support which will allow you to build a kernel much larger than is
> > > necessary for your platform by including other platforms in it.  Sorry,
> > > that's just stupid.
> > 
> > Right, it will allow me to build a much bigger kernel (but I don't need
> > to). And it allows me a few more things (yes please).
> 
> "a few more things" - I count two things which you've mentioned so far,
> both of which can be sorted out.  Anything else?
Nothing I'm aware at the moment. I will address your two suggestions
soon. Still I wonder if going the multi-arch route is the right thing to
do now that it is (still) easy. And if it's only because it matches what
the MMU machines are doing and so uses more better tested stuff.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |