[PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP

[PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP

[Chris Brandt]

Since ARCH_MULTIPLATFORM explicitly selects ARM_PATCH_PHYS_VIRT, even
though ARCH_MULTIPLATFORM has 'depends on !XIP_KERNEL', ARM_PATCH_PHYS_VIRT
is still forcibly selected. The result is that PHYS_OFFSET depends on
!ARM_PATCH_PHYS_VIRT. This means you cannot enter a physical RAM address
for an XIP kernel and you cannot build.

Given that it is already clear in the Kconfig that ARM_PATCH_PHYS_VIRT and
XIP_KERNEL do not go well together (read the help for ARM_PATCH_PHYS_VIRT),
adding this condition to ARCH_MULTIPLATFORM is logical and will fix this
build issue.

Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index bf8d86d..c97bd2c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -330,7 +330,7 @@ config ARCH_MULTIPLATFORM
 	bool "Allow multiple platforms to be selected"
 	depends on MMU
 	select ARM_HAS_SG_CHAIN
-	select ARM_PATCH_PHYS_VIRT
+	select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL
 	select AUTO_ZRELADDR
 	select CLKSRC_OF
 	select COMMON_CLK
-- 
2.10.1

[PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP

[Russell King - ARM Linux]

On Wed, Feb 08, 2017 at 12:22:09PM -0500, Chris Brandt wrote:
> Since ARCH_MULTIPLATFORM explicitly selects ARM_PATCH_PHYS_VIRT, even
> though ARCH_MULTIPLATFORM has 'depends on !XIP_KERNEL', ARM_PATCH_PHYS_VIRT
> is still forcibly selected. The result is that PHYS_OFFSET depends on
> !ARM_PATCH_PHYS_VIRT. This means you cannot enter a physical RAM address
> for an XIP kernel and you cannot build.
> 
> Given that it is already clear in the Kconfig that ARM_PATCH_PHYS_VIRT and
> XIP_KERNEL do not go well together (read the help for ARM_PATCH_PHYS_VIRT),
> adding this condition to ARCH_MULTIPLATFORM is logical and will fix this
> build issue.

And, ergo, multiplatform kernels and XIP_KERNEL don't go together either.
Think about it...

This is why I regard those who want multiplatform to work with options
such as XIP_KERNEL and NOMMU to be insane.

Please, can we stop trying to make multiplatform also cover the situations
where only a single class of platforms works (iow, the old way we used to
deal with platforms is the most sensible solution.)

IMHO multiplatform was done right for multiplatform but at the expense of
totally breaking stuff like XIP and noMMU.  We need to stop trying to
bend multiplatform to cover XIP and noMMU, but instead restore the old
way of handling this _along_ with multiplatform as an additional option.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP

[Geert Uytterhoeven]

Hi Russell,

On Wed, Feb 8, 2017 at 6:44 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Feb 08, 2017 at 12:22:09PM -0500, Chris Brandt wrote:
>> Since ARCH_MULTIPLATFORM explicitly selects ARM_PATCH_PHYS_VIRT, even
>> though ARCH_MULTIPLATFORM has 'depends on !XIP_KERNEL', ARM_PATCH_PHYS_VIRT
>> is still forcibly selected. The result is that PHYS_OFFSET depends on
>> !ARM_PATCH_PHYS_VIRT. This means you cannot enter a physical RAM address
>> for an XIP kernel and you cannot build.
>>
>> Given that it is already clear in the Kconfig that ARM_PATCH_PHYS_VIRT and
>> XIP_KERNEL do not go well together (read the help for ARM_PATCH_PHYS_VIRT),
>> adding this condition to ARCH_MULTIPLATFORM is logical and will fix this
>> build issue.
>
> And, ergo, multiplatform kernels and XIP_KERNEL don't go together either.
> Think about it...
>
> This is why I regard those who want multiplatform to work with options
> such as XIP_KERNEL and NOMMU to be insane.
>
> Please, can we stop trying to make multiplatform also cover the situations
> where only a single class of platforms works (iow, the old way we used to
> deal with platforms is the most sensible solution.)
>
> IMHO multiplatform was done right for multiplatform but at the expense of
> totally breaking stuff like XIP and noMMU.  We need to stop trying to
> bend multiplatform to cover XIP and noMMU, but instead restore the old
> way of handling this _along_ with multiplatform as an additional option.

The problem is that "multiplatform" may mean one of two things:
  1. Build a single kernel that can run on multiple platforms.
     This is tricky when enabling XIP and/or NOMMU, as the physical parameters
     must be compatible with all platforms. But building a kernel with the
     right parameters is the responsibility of the user.
     I.e. don't shoot yourself in the foot.
  2. Your platform uses the arch/arm multiplatform framework.

As everything is being migrated to 2, not allowing XIP and/or NOMMU on
"multiplatform" is IMHO an insane limitation.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP

[Russell King - ARM Linux]

On Wed, Feb 08, 2017 at 06:53:14PM +0100, Geert Uytterhoeven wrote:
> The problem is that "multiplatform" may mean one of two things:
>   1. Build a single kernel that can run on multiple platforms.
>      This is tricky when enabling XIP and/or NOMMU, as the physical parameters
>      must be compatible with all platforms. But building a kernel with the
>      right parameters is the responsibility of the user.
>      I.e. don't shoot yourself in the foot.
>   2. Your platform uses the arch/arm multiplatform framework.
> 
> As everything is being migrated to 2, not allowing XIP and/or NOMMU on
> "multiplatform" is IMHO an insane limitation.

There _isn't_ a framework.  What there is are a collection of Kconfig
options that multiplatform provides you that can also be selected by
any other configuration route.

(2) really doesn't apply.

The real issue is that board stuff ends up with a "depends on MULTI_xxx"
which needs to be bypassed.  That's pretty easy to do - I've done it as
a proof of concept a few years ago when this exact same thing came up
for !MMU, and since then I've been NAKing and refusing to apply patches
that try to re-use multiplat for !MMU.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP

[Geert Uytterhoeven]

Hi Russell,

On Wed, Feb 8, 2017 at 7:39 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Feb 08, 2017 at 06:53:14PM +0100, Geert Uytterhoeven wrote:
>> The problem is that "multiplatform" may mean one of two things:
>>   1. Build a single kernel that can run on multiple platforms.
>>      This is tricky when enabling XIP and/or NOMMU, as the physical parameters
>>      must be compatible with all platforms. But building a kernel with the
>>      right parameters is the responsibility of the user.
>>      I.e. don't shoot yourself in the foot.
>>   2. Your platform uses the arch/arm multiplatform framework.
>>
>> As everything is being migrated to 2, not allowing XIP and/or NOMMU on
>> "multiplatform" is IMHO an insane limitation.
>
> There _isn't_ a framework.  What there is are a collection of Kconfig
> options that multiplatform provides you that can also be selected by
> any other configuration route.
>
> (2) really doesn't apply.
>
> The real issue is that board stuff ends up with a "depends on MULTI_xxx"
> which needs to be bypassed.  That's pretty easy to do - I've done it as
> a proof of concept a few years ago when this exact same thing came up
> for !MMU, and since then I've been NAKing and refusing to apply patches
> that try to re-use multiplat for !MMU.

So you mean this:

--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -31,7 +31,7 @@ config ARCH_RMOBILE

 menuconfig ARCH_RENESAS
        bool "Renesas ARM SoCs"
-       depends on ARCH_MULTI_V7 && MMU
+       depends on MMU
        select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
        select ARCH_SHMOBILE
        select ARCH_SHMOBILE_MULTI

?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP

[Russell King - ARM Linux]

On Wed, Feb 08, 2017 at 07:46:55PM +0100, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Wed, Feb 8, 2017 at 7:39 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Wed, Feb 08, 2017 at 06:53:14PM +0100, Geert Uytterhoeven wrote:
> >> The problem is that "multiplatform" may mean one of two things:
> >>   1. Build a single kernel that can run on multiple platforms.
> >>      This is tricky when enabling XIP and/or NOMMU, as the physical parameters
> >>      must be compatible with all platforms. But building a kernel with the
> >>      right parameters is the responsibility of the user.
> >>      I.e. don't shoot yourself in the foot.
> >>   2. Your platform uses the arch/arm multiplatform framework.
> >>
> >> As everything is being migrated to 2, not allowing XIP and/or NOMMU on
> >> "multiplatform" is IMHO an insane limitation.
> >
> > There _isn't_ a framework.  What there is are a collection of Kconfig
> > options that multiplatform provides you that can also be selected by
> > any other configuration route.
> >
> > (2) really doesn't apply.
> >
> > The real issue is that board stuff ends up with a "depends on MULTI_xxx"
> > which needs to be bypassed.  That's pretty easy to do - I've done it as
> > a proof of concept a few years ago when this exact same thing came up
> > for !MMU, and since then I've been NAKing and refusing to apply patches
> > that try to re-use multiplat for !MMU.
> 
> So you mean this:
> 
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -31,7 +31,7 @@ config ARCH_RMOBILE
> 
>  menuconfig ARCH_RENESAS
>         bool "Renesas ARM SoCs"
> -       depends on ARCH_MULTI_V7 && MMU
> +       depends on MMU
>         select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
>         select ARCH_SHMOBILE
>         select ARCH_SHMOBILE_MULTI

I don't see the connection, sorry.  That looks totally broken to me,
because you now end up being able to select it when you have (eg)
something like ARCH_RPC enabled, and that's totally insane.

If you think the above patch in some way represents what I was saying,
that's wrong as well.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP

[Chris Brandt]

On Wednesday, February 08, 2017, Russell King wrote:
> On Wed, Feb 08, 2017 at 12:22:09PM -0500, Chris Brandt wrote:
> > Since ARCH_MULTIPLATFORM explicitly selects ARM_PATCH_PHYS_VIRT, even
> > though ARCH_MULTIPLATFORM has 'depends on !XIP_KERNEL',
> > ARM_PATCH_PHYS_VIRT is still forcibly selected. The result is that
> > PHYS_OFFSET depends on !ARM_PATCH_PHYS_VIRT. This means you cannot
> > enter a physical RAM address for an XIP kernel and you cannot build.
> >
> > Given that it is already clear in the Kconfig that ARM_PATCH_PHYS_VIRT
> > and XIP_KERNEL do not go well together (read the help for
> > ARM_PATCH_PHYS_VIRT), adding this condition to ARCH_MULTIPLATFORM is
> > logical and will fix this build issue.
> 
> And, ergo, multiplatform kernels and XIP_KERNEL don't go together either.
> Think about it...
> 
> This is why I regard those who want multiplatform to work with options
> such as XIP_KERNEL and NOMMU to be insane.

It's not so much that I want multiplatform and XIP together (because
absolutely they do not), it's that the SOC I care about is shoved under
the multiplatform umbrella.


> Please, can we stop trying to make multiplatform also cover the situations
> where only a single class of platforms works (iow, the old way we used to
> deal with platforms is the most sensible solution.)
> 
> IMHO multiplatform was done right for multiplatform but at the expense of
> totally breaking stuff like XIP and noMMU.  We need to stop trying to bend
> multiplatform to cover XIP and noMMU, but instead restore the old way of
> handling this _along_ with multiplatform as an additional option.

A while back there was a grandiose idea if it would be great you only selected
1 (and only 1) of the platforms in a multiplatform arch, then and only then
would the XIP option become available for you.
However, I tried everything I could, but the kbuild system just doesn't have
a way to do such a thing. So, I'm back to shoving XIP and multiplatform
together.

So, any ideas on how I can take an ARCH_xxx and make it show up under
both single and multiplatform??

Can I get away with making a separate ARCH_xxx_XIP that selects ARCH_xxx?

Of course I just tested 4.10-rc7 for XIP+MMU and it works fine, but I have
to hack the Kconfig each time.

Chris

[PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP

[Russell King - ARM Linux]

On Wed, Feb 08, 2017 at 06:00:26PM +0000, Chris Brandt wrote:
> On Wednesday, February 08, 2017, Russell King wrote:
> > On Wed, Feb 08, 2017 at 12:22:09PM -0500, Chris Brandt wrote:
> > > Since ARCH_MULTIPLATFORM explicitly selects ARM_PATCH_PHYS_VIRT, even
> > > though ARCH_MULTIPLATFORM has 'depends on !XIP_KERNEL',
> > > ARM_PATCH_PHYS_VIRT is still forcibly selected. The result is that
> > > PHYS_OFFSET depends on !ARM_PATCH_PHYS_VIRT. This means you cannot
> > > enter a physical RAM address for an XIP kernel and you cannot build.
> > >
> > > Given that it is already clear in the Kconfig that ARM_PATCH_PHYS_VIRT
> > > and XIP_KERNEL do not go well together (read the help for
> > > ARM_PATCH_PHYS_VIRT), adding this condition to ARCH_MULTIPLATFORM is
> > > logical and will fix this build issue.
> > 
> > And, ergo, multiplatform kernels and XIP_KERNEL don't go together either.
> > Think about it...
> > 
> > This is why I regard those who want multiplatform to work with options
> > such as XIP_KERNEL and NOMMU to be insane.
> 
> It's not so much that I want multiplatform and XIP together (because
> absolutely they do not), it's that the SOC I care about is shoved under
> the multiplatform umbrella.

Right, and that's what I hear all the time, but it's not really an
argument that stacks up.

We have the big "ARM system type" choice, one of the options there is
to build for multi-platform.  Historically, it's been to select the
SoC family - where "SoC family" means a group of SoCs that could be
built together into one image without all the fun and games of V:P
patching, auto-zreladdr, etc - _exactly_ the conditions that !MMU
and XIP_KERNEL depended upon[*].

To allow a SOC to be built without multiplatform, you add another
option to that choice statement (exactly as we used to have before
multiplatform).  For the sake of argument, let's say we're talking
about iMX ARMv7 SoCs.  So, let's call it ARM_SOC_IMX_V7.

You add to that all the select statements that multiplatform gives
you that you need for that platform, omitting those that don't make
sense (like virt/phys patching), making it depend on XIP_KERNEL and/or
!MMU.

Then you change the mach-*/Kconfig entry like this:

menuconfig ARCH_MXC
-       bool "Freescale i.MX family"
-       depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M
+       bool "Freescale i.MX family" if !ARM_SOC_IMX_V7
+       depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M ||\
+		ARM_SOC_IMX_V7
+	default ARM_SOC_IMX_V7

and also modify the if ARCH_MULTI_V7 to also allow that section if
ARM_SOC_IMX_V7 is enabled.


* - that's the problem - multiplatform went head-long into the "we
don't like the existing solution, we need to move everyone away, and
let's hope no one wants XIP_KERNEL or !MMU now".  So we went from a
relatively good solution that didn't support building diverse platforms
together to one that rather sucks for XIP_KERNEL and !MMU.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP

[Chris Brandt]

Hello Russell,

On Wednesday, February 08, 2017, Russell King wrote:
> We have the big "ARM system type" choice, one of the options there is to
> build for multi-platform.  Historically, it's been to select the SoC
> family - where "SoC family" means a group of SoCs that could be built
> together into one image without all the fun and games of V:P patching,
> auto-zreladdr, etc - _exactly_ the conditions that !MMU and XIP_KERNEL
> depended upon[*].
> 
> To allow a SOC to be built without multiplatform, you add another option
> to that choice statement (exactly as we used to have before multiplatform).
> For the sake of argument, let's say we're talking about iMX ARMv7 SoCs.
> So, let's call it ARM_SOC_IMX_V7.
> 
> You add to that all the select statements that multiplatform gives you
> that you need for that platform, omitting those that don't make sense
> (like virt/phys patching), making it depend on XIP_KERNEL and/or !MMU.
> 
> Then you change the mach-*/Kconfig entry like this:
> 
> menuconfig ARCH_MXC
> -       bool "Freescale i.MX family"
> -       depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 ||
> ARM_SINGLE_ARMV7M
> +       bool "Freescale i.MX family" if !ARM_SOC_IMX_V7
> +       depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 ||
> ARM_SINGLE_ARMV7M ||\
> +		ARM_SOC_IMX_V7
> +	default ARM_SOC_IMX_V7
> 
> and also modify the if ARCH_MULTI_V7 to also allow that section if
> ARM_SOC_IMX_V7 is enabled.
> 
> 
> * - that's the problem - multiplatform went head-long into the "we don't
> like the existing solution, we need to move everyone away, and let's hope
> no one wants XIP_KERNEL or !MMU now".  So we went from a relatively good
> solution that didn't support building diverse platforms together to one
> that rather sucks for XIP_KERNEL and !MMU.


So, a quick hack and it seems that works. I get my family of SoC that I
can select XIP_KERNEL.

I'll do some build experiments, and if it looks like it will work, I'll
send off a patch to see how opposes it.
For the most part, if everyone is off playing in the multiplatform pool,
me creating a new ARM V7 single-platform pool won't affect anyone.



Chris