| Message ID | 20170208172209.31673-1-chris.brandt@renesas.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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@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
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
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.
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.
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
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
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(-)