Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

[ adding linux-kbuild for their input ]

On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:

> I'm afraid adding (duplicating) machine entries for nommu support is not a
> sustainable solutions. Any machine can run a nommu kernel, in theory.
> 
> I'm aware of the objection "but you cannot build a nommu kernel that can
> boot on multiple systems".  That's true (unless RAM/FLASH addresses are the
> same). So don't do that.
> 
> All of the above is true for XIP, too, hence applies with s/nommu/XIP/.
> One more reason not to have this duplication.
> 
> The current "ARM multiplatform" has actually two meanings:
>   1. It groups platforms that follow the "ARM multiplatform" framework,
>   2. It allows to build a single kernel that can be booted on multiple
>      platforms.
> To avoid the duplication, I think 2 should be relaxed when specialized
> options like XIP or NOMMU are selected.
> 
> I've just sent a patch to do that.

Your patch isn't wrong per se.  But it is not enough. The issue here 
would be easily fixed with some kconfig extension so that:

- If XIP or NOMMU is selected then only one target in the multiplatform 
  set can be selected, basically turning it into a choice menu.

- If more than one multiplatform targets is selected then XIP and NOMMU 
  can no longere be selected.

I don't know how this could be expressed but the implementation might 
not be that hard.


Nicolas

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

On Thursday, June 21, 2018 1, Nicolas Pitre wrote:
> > I've just sent a patch to do that.
> 
> Your patch isn't wrong per se.  But it is not enough. The issue here
> would be easily fixed with some kconfig extension so that:
> 
> - If XIP or NOMMU is selected then only one target in the multiplatform
>   set can be selected, basically turning it into a choice menu.
> 
> - If more than one multiplatform targets is selected then XIP and NOMMU
>   can no longere be selected.
>

Over the years I tried to tackle this issue in multiple different ways, 
while still staying in the limitations of kbuild.
Basically, everything was shot down for one reason or another (or the 
only way to do it is really ugly...so I didn't even ask).

kbuild doesn't really have a mutually exclusive property that can be 
dynamically set/cleared.


In the end, I saw only 2 paths for adding XIP to ARM MMU builds:

1) Modify kbuild to give the ability as stated above.

2) Make XIP builds somehow be able to run at multiple physical address 
by modifying the binaries post-build (Arnd's suggestion).


What I have been doing is simply applying this patch to arch/arm/Kconifg
before every XIP KERNEL build:

 config XIP_KERNEL
 	bool "Kernel Execute-In-Place from ROM"
-	depends on !ARM_LPAE && !ARCH_MULTIPLATFORM
+	depends on !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



Chris

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Geert Uytterhoeven]

Hi Chris,

On Thu, Jun 21, 2018 at 6:45 PM Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Thursday, June 21, 2018 1, Nicolas Pitre wrote:
> > > I've just sent a patch to do that.
> >
> > Your patch isn't wrong per se.  But it is not enough. The issue here
> > would be easily fixed with some kconfig extension so that:
> >
> > - If XIP or NOMMU is selected then only one target in the multiplatform
> >   set can be selected, basically turning it into a choice menu.
> >
> > - If more than one multiplatform targets is selected then XIP and NOMMU
> >   can no longere be selected.
>
> Over the years I tried to tackle this issue in multiple different ways,
> while still staying in the limitations of kbuild.
> Basically, everything was shot down for one reason or another (or the
> only way to do it is really ugly...so I didn't even ask).
>
> kbuild doesn't really have a mutually exclusive property that can be
> dynamically set/cleared.
>
> In the end, I saw only 2 paths for adding XIP to ARM MMU builds:
>
> 1) Modify kbuild to give the ability as stated above.

Would that actually help, or would it only give you a false feeling of safety?
Most "multiplatform" sub-architectures (like iMX or "shmobile") still have
multiple families and SoCs, so you have to repeat the exercise at that level.

Still, even when configuring a kernel for a single SoC, the final board
selection is at the DTS level.

Conclusion: If you want NOMMU and/or XIP, you have to know what you're doing,
and hand-holding at whatever level may not save you from making mistakes.

> 2) Make XIP builds somehow be able to run at multiple physical address
> by modifying the binaries post-build (Arnd's suggestion).

That's actually an interesting one: no manual configuration (iff parameters
would be extracted from the DTB), so nothing can go wrong ;-)
I guess it applies to NOMMU, too.

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

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

Hi Geert,

On Friday, June 22, 2018, Geert Uytterhoeven wrote:
> > 1) Modify kbuild to give the ability as stated above.
> 
> Would that actually help, or would it only give you a false feeling of
> safety?

Yup!
But I don't really care about safty. I just want to be able to build my images without having to hack Kconfig.


> Conclusion: If you want NOMMU and/or XIP, you have to know what you're
> doing,
> and hand-holding at whatever level may not save you from making mistakes.

I agree.
And, you'll require your own kernel config in order to cut out all the 
extra stuff that your system doesn't need.


> > 2) Make XIP builds somehow be able to run at multiple physical address
> > by modifying the binaries post-build (Arnd's suggestion).
> 
> That's actually an interesting one: no manual configuration (iff
> parameters
> would be extracted from the DTB), so nothing can go wrong ;-)
> I guess it applies to NOMMU, too.

For the hard coded memory address, it's only need at the very beginning 
of boot in order to set up a temporary stack, but soon the DTB is read 
and life is good. So in theory, the memory address could be passed in 
with a register.

For the hard coded ROM address, that needs to be available at run time 
in order to do the virt_to_phys translation. But, the idea is to change 
that from a #define to a global variable.

It sounded like it might work...although I never got around to hacking 
the code to see if it would or not because at the end of the day, it 
didn't provide any real value to ab XIP Linux system.


Chris

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote:
> [ adding linux-kbuild for their input ]
> 
> On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:
> 
> > I'm afraid adding (duplicating) machine entries for nommu support is not a
> > sustainable solutions. Any machine can run a nommu kernel, in theory.
> > 
> > I'm aware of the objection "but you cannot build a nommu kernel that can
> > boot on multiple systems".  That's true (unless RAM/FLASH addresses are the
> > same). So don't do that.
> > 
> > All of the above is true for XIP, too, hence applies with s/nommu/XIP/.
> > One more reason not to have this duplication.
> > 
> > The current "ARM multiplatform" has actually two meanings:
> >   1. It groups platforms that follow the "ARM multiplatform" framework,
> >   2. It allows to build a single kernel that can be booted on multiple
> >      platforms.
> > To avoid the duplication, I think 2 should be relaxed when specialized
> > options like XIP or NOMMU are selected.
> > 
> > I've just sent a patch to do that.
> 
> Your patch isn't wrong per se.  But it is not enough. The issue here 
> would be easily fixed with some kconfig extension so that:
> 
> - If XIP or NOMMU is selected then only one target in the multiplatform 
>   set can be selected, basically turning it into a choice menu.

I don't think that's how it should work.  Consider the V7M case, where
we have better standardisation of the physical address layout than
previous ARM devices.  We have three platforms which are V7M compliant:

- AT91
- iMX
- STM32

These have separate symbols:

menuconfig ARCH_AT91
	bool "AT91/Microchip SoCs"
	depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M

menuconfig ARCH_MXC
	bool "Freescale i.MX family"
	depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M

menuconfig ARCH_STM32
	bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7

With your suggestion, you would become only build a kernel for one of
these, but that is not the case today: it's possible to build a single
kernel which supports all these platforms.

So, I don't think we want your suggestion.

What we have today is flexible enough that we can have the best of
multiplatform vs the restrictions caused by the variance in hardware.
IOW, what we have is a compromise, which I believe is a reasonable,
functional, and good compromise that fits the real world physical
conditions with the least amount of overhead.

Every other suggestion I've seen posted has drawbacks, from artificially
restricting what can be selected (eg, as in your case) to allowing more
platforms to be selected thereby creating non-bootable kernels (eg, as
in Geert's case.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:

> On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote:
> > [ adding linux-kbuild for their input ]
> > 
> > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:
> > 
> > > I've just sent a patch to do that.
> > 
> > Your patch isn't wrong per se.  But it is not enough. The issue here 
> > would be easily fixed with some kconfig extension so that:
> > 
> > - If XIP or NOMMU is selected then only one target in the multiplatform 
> >   set can be selected, basically turning it into a choice menu.
> 
> I don't think that's how it should work.  Consider the V7M case, where
> we have better standardisation of the physical address layout than
> previous ARM devices.  We have three platforms which are V7M compliant:
> 
> - AT91
> - iMX
> - STM32
> 
> These have separate symbols:
> 
> menuconfig ARCH_AT91
> 	bool "AT91/Microchip SoCs"
> 	depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M
> 
> menuconfig ARCH_MXC
> 	bool "Freescale i.MX family"
> 	depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M
> 
> menuconfig ARCH_STM32
> 	bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7
> 
> With your suggestion, you would become only build a kernel for one of
> these, but that is not the case today: it's possible to build a single
> kernel which supports all these platforms.

That is still something that could be accommodated if the kconfig 
language was more accommodating. The problem comes from the fact that 
some options are mutually exclusive, like platforms with conflicting 
memory maps and XIP.

Leaving your example above aside for the moment, let's just pick the 
ARCH_MULTIPLATFORM group which is always the problematic one in 
practice. We need a way to limit platform selection within that set to 
only one platform among them all if XIP_KERNEL is set. And that is 
impossible to express with the kconfig language today.

So, my assertion is that, unless someone volunteers a solution to the 
kconfig language to express mutual exclusion between symbols, this issue 
just can't be fixed properly.


Nicolas

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Geert Uytterhoeven]

Hi Nicolas,

On Fri, Jun 22, 2018 at 5:26 PM Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote:
> > > [ adding linux-kbuild for their input ]
> > >
> > > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:
> > > > I've just sent a patch to do that.
> > >
> > > Your patch isn't wrong per se.  But it is not enough. The issue here
> > > would be easily fixed with some kconfig extension so that:
> > >
> > > - If XIP or NOMMU is selected then only one target in the multiplatform
> > >   set can be selected, basically turning it into a choice menu.
> >
> > I don't think that's how it should work.  Consider the V7M case, where
> > we have better standardisation of the physical address layout than
> > previous ARM devices.  We have three platforms which are V7M compliant:
> >
> > - AT91
> > - iMX
> > - STM32
> >
> > These have separate symbols:
> >
> > menuconfig ARCH_AT91
> >       bool "AT91/Microchip SoCs"
> >       depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M
> >
> > menuconfig ARCH_MXC
> >       bool "Freescale i.MX family"
> >       depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M
> >
> > menuconfig ARCH_STM32
> >       bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7
> >
> > With your suggestion, you would become only build a kernel for one of
> > these, but that is not the case today: it's possible to build a single
> > kernel which supports all these platforms.
>
> That is still something that could be accommodated if the kconfig
> language was more accommodating. The problem comes from the fact that
> some options are mutually exclusive, like platforms with conflicting
> memory maps and XIP.
>
> Leaving your example above aside for the moment, let's just pick the
> ARCH_MULTIPLATFORM group which is always the problematic one in
> practice. We need a way to limit platform selection within that set to
> only one platform among them all if XIP_KERNEL is set. And that is
> impossible to express with the kconfig language today.
>
> So, my assertion is that, unless someone volunteers a solution to the
> kconfig language to express mutual exclusion between symbols, this issue
> just can't be fixed properly.

Even that would not be sufficient, as these days the final target platform
selection is not by a Kconfig symbol, but by a DT[SB] file.

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

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Geert Uytterhoeven wrote:

> Hi Nicolas,
> 
> On Fri, Jun 22, 2018 at 5:26 PM Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > > On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote:
> > > > [ adding linux-kbuild for their input ]
> > > >
> > > > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote:
> > > > > I've just sent a patch to do that.
> > > >
> > > > Your patch isn't wrong per se.  But it is not enough. The issue here
> > > > would be easily fixed with some kconfig extension so that:
> > > >
> > > > - If XIP or NOMMU is selected then only one target in the multiplatform
> > > >   set can be selected, basically turning it into a choice menu.
> > >
> > > I don't think that's how it should work.  Consider the V7M case, where
> > > we have better standardisation of the physical address layout than
> > > previous ARM devices.  We have three platforms which are V7M compliant:
> > >
> > > - AT91
> > > - iMX
> > > - STM32
> > >
> > > These have separate symbols:
> > >
> > > menuconfig ARCH_AT91
> > >       bool "AT91/Microchip SoCs"
> > >       depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M
> > >
> > > menuconfig ARCH_MXC
> > >       bool "Freescale i.MX family"
> > >       depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M
> > >
> > > menuconfig ARCH_STM32
> > >       bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7
> > >
> > > With your suggestion, you would become only build a kernel for one of
> > > these, but that is not the case today: it's possible to build a single
> > > kernel which supports all these platforms.
> >
> > That is still something that could be accommodated if the kconfig
> > language was more accommodating. The problem comes from the fact that
> > some options are mutually exclusive, like platforms with conflicting
> > memory maps and XIP.
> >
> > Leaving your example above aside for the moment, let's just pick the
> > ARCH_MULTIPLATFORM group which is always the problematic one in
> > practice. We need a way to limit platform selection within that set to
> > only one platform among them all if XIP_KERNEL is set. And that is
> > impossible to express with the kconfig language today.
> >
> > So, my assertion is that, unless someone volunteers a solution to the
> > kconfig language to express mutual exclusion between symbols, this issue
> > just can't be fixed properly.
> 
> Even that would not be sufficient, as these days the final target platform
> selection is not by a Kconfig symbol, but by a DT[SB] file.

That is no longer a kernel config/build issue if you the system 
integrator put an XIP kernel on a target with the wrong DT.

The XIP kernel does require that you provide the actual memory base 
address as a constant to the build system but that could be extracted 
directly from the DT data if having a kconfig prompt for that is too 
unwieldy. The new kconfig macro language in mainline could even be 
leveraged to do that at config time.

All that is possible already. But config symbol mutual exclusion is not.


Nicolas

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 11:57:32AM -0400, Nicolas Pitre wrote:
> That is no longer a kernel config/build issue if you the system 
> integrator put an XIP kernel on a target with the wrong DT.
> 
> The XIP kernel does require that you provide the actual memory base 
> address as a constant to the build system but that could be extracted 
> directly from the DT data if having a kconfig prompt for that is too 
> unwieldy. The new kconfig macro language in mainline could even be 
> leveraged to do that at config time.

That is actually incorrect - you're too used to the dynamic fixup of
virt_to_phys() and friends now!

Given that XIP is typically used in environments where the kernel text
is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
disabled, we use a constant translation, based upon the build-time
CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.

The early assembler relies upon these settings - which must be known
before we enable the MMU.  As such, DT parsing is not available to us
at that point (as we can't run any C code, because we won't be calling
it at the address it was linked for.)

I suppose someone who was sufficiently motivated could write assembly-
based parsing of DT to extract the memory regions and work out what the
right settings are.  Is there really the motivation to do that - there
was a burst of XIP interest a few releases ago but it seems to have
tailed off.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:

> On Fri, Jun 22, 2018 at 11:57:32AM -0400, Nicolas Pitre wrote:
> > That is no longer a kernel config/build issue if you the system 
> > integrator put an XIP kernel on a target with the wrong DT.
> > 
> > The XIP kernel does require that you provide the actual memory base 
> > address as a constant to the build system but that could be extracted 
> > directly from the DT data if having a kconfig prompt for that is too 
> > unwieldy. The new kconfig macro language in mainline could even be 
> > leveraged to do that at config time.
> 
> That is actually incorrect - you're too used to the dynamic fixup of
> virt_to_phys() and friends now!
> 
> Given that XIP is typically used in environments where the kernel text
> is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> disabled, we use a constant translation, based upon the build-time
> CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> 
> The early assembler relies upon these settings - which must be known
> before we enable the MMU.  As such, DT parsing is not available to us
> at that point (as we can't run any C code, because we won't be calling
> it at the address it was linked for.)

I think you got me wrong.  I meant DT parsing at config or build time, 
not at run time.

Latest mainline allows kconfig files to call out to external programs 
now.


Nicolas

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote:
> On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > That is actually incorrect - you're too used to the dynamic fixup of
> > virt_to_phys() and friends now!
> > 
> > Given that XIP is typically used in environments where the kernel text
> > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> > disabled, we use a constant translation, based upon the build-time
> > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> > 
> > The early assembler relies upon these settings - which must be known
> > before we enable the MMU.  As such, DT parsing is not available to us
> > at that point (as we can't run any C code, because we won't be calling
> > it at the address it was linked for.)
> 
> I think you got me wrong.  I meant DT parsing at config or build time, 
> not at run time.

That seems backwards and complicated.  It seems this would end up
with:

- you configure the kernel
- build the dtb files
- reconfigure parsing a specific dtb file built in the previous step
- build the kernel proper

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:

> On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote:
> > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > > That is actually incorrect - you're too used to the dynamic fixup of
> > > virt_to_phys() and friends now!
> > > 
> > > Given that XIP is typically used in environments where the kernel text
> > > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> > > disabled, we use a constant translation, based upon the build-time
> > > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> > > 
> > > The early assembler relies upon these settings - which must be known
> > > before we enable the MMU.  As such, DT parsing is not available to us
> > > at that point (as we can't run any C code, because we won't be calling
> > > it at the address it was linked for.)
> > 
> > I think you got me wrong.  I meant DT parsing at config or build time, 
> > not at run time.
> 
> That seems backwards and complicated.  It seems this would end up
> with:
> 
> - you configure the kernel
> - build the dtb files
> - reconfigure parsing a specific dtb file built in the previous step
> - build the kernel proper

... or just stick the right value manually when prompting for 
XIP_PHYS_ADDR.  Really, depending on DT is a non issue that only pulls 
the conversation away from the actual kconfig language limitation that 
needs to be overcome.


Nicolas

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 12:54:18PM -0400, Nicolas Pitre wrote:
> On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> 
> > On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote:
> > > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > > > That is actually incorrect - you're too used to the dynamic fixup of
> > > > virt_to_phys() and friends now!
> > > > 
> > > > Given that XIP is typically used in environments where the kernel text
> > > > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> > > > disabled, we use a constant translation, based upon the build-time
> > > > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> > > > 
> > > > The early assembler relies upon these settings - which must be known
> > > > before we enable the MMU.  As such, DT parsing is not available to us
> > > > at that point (as we can't run any C code, because we won't be calling
> > > > it at the address it was linked for.)
> > > 
> > > I think you got me wrong.  I meant DT parsing at config or build time, 
> > > not at run time.
> > 
> > That seems backwards and complicated.  It seems this would end up
> > with:
> > 
> > - you configure the kernel
> > - build the dtb files
> > - reconfigure parsing a specific dtb file built in the previous step
> > - build the kernel proper
> 
> ... or just stick the right value manually when prompting for 
> XIP_PHYS_ADDR.  Really, depending on DT is a non issue that only pulls 
> the conversation away from the actual kconfig language limitation that 
> needs to be overcome.

Which is _exactly_ what we do today, so I don't see what point you're
making in this sub-thread.

I thought we were discussing about getting Kconfig to obtain settings
from dtb files.  If you have a point to make, please don't make the
discussion impossible by changing your point, it makes it a waste of
time trying to have a discussion.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:

> On Fri, Jun 22, 2018 at 12:54:18PM -0400, Nicolas Pitre wrote:
> > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > 
> > > On Fri, Jun 22, 2018 at 12:21:33PM -0400, Nicolas Pitre wrote:
> > > > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote:
> > > > > That is actually incorrect - you're too used to the dynamic fixup of
> > > > > virt_to_phys() and friends now!
> > > > > 
> > > > > Given that XIP is typically used in environments where the kernel text
> > > > > is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> > > > > disabled, we use a constant translation, based upon the build-time
> > > > > CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.
> > > > > 
> > > > > The early assembler relies upon these settings - which must be known
> > > > > before we enable the MMU.  As such, DT parsing is not available to us
> > > > > at that point (as we can't run any C code, because we won't be calling
> > > > > it at the address it was linked for.)
> > > > 
> > > > I think you got me wrong.  I meant DT parsing at config or build time, 
> > > > not at run time.
> > > 
> > > That seems backwards and complicated.  It seems this would end up
> > > with:
> > > 
> > > - you configure the kernel
> > > - build the dtb files
> > > - reconfigure parsing a specific dtb file built in the previous step
> > > - build the kernel proper
> > 
> > ... or just stick the right value manually when prompting for 
> > XIP_PHYS_ADDR.  Really, depending on DT is a non issue that only pulls 
> > the conversation away from the actual kconfig language limitation that 
> > needs to be overcome.
> 
> Which is _exactly_ what we do today, so I don't see what point you're
> making in this sub-thread.

I was merely trying to show Geert that DT dependencies are not an issue 
after he brought that as an argument.


Nicolas

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

> That is actually incorrect - you're too used to the dynamic fixup of
> virt_to_phys() and friends now!
> 
> Given that XIP is typically used in environments where the kernel text
> is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT.  When
> disabled, we use a constant translation, based upon the build-time
> CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings.

CONFIG_PHYS_OFFSET (RAM address) and CONFIG_XIP_PHYS_ADDR (ROM address) 
are set today in kconfig.

Instead of having them hard coded, they could be global variables set 
during boot.

CONFIG_XIP_PHYS_ADDR could be determined by looking at the value of the 
PC.

CONFIG_PHYS_OFFSET is still the issue because that has to be passed in 
via boot register.


> I suppose someone who was sufficiently motivated could write assembly-
> based parsing of DT to extract the memory regions and work out what the
> right settings are.  Is there really the motivation to do that - there
> was a burst of XIP interest a few releases ago but it seems to have
> tailed off.

Because at least for me, by simply removing the !ARCH_MULTIPLATFORM 
dependency for setting XIP_KERNEL works perfectly fine for building and 
running kernels.

So, it's hard to justify doing a lot more work than what can be done 
today with just 1 line edit.

I still test every kernel release to make XIP_KERNEL still works.

Actually, I just tested 4.18.0-rc1 this morning.


Chris

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

On Friday, June 22, 2018 1, Nicolas Pitre wrote:
> All that is possible already. But config symbol mutual exclusion is not.

I still don't understand why we need some false sense of security for 
only selecting 1 platform.

There are probably plenty of kernel config options that you could enable
that would break any number of systems.

So, why do we feel that XIP_KERNEL needs a warm safety blanket around 
it?

Chris

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Chris Brandt wrote:

> On Friday, June 22, 2018 1, Nicolas Pitre wrote:
> > All that is possible already. But config symbol mutual exclusion is not.
> 
> I still don't understand why we need some false sense of security for 
> only selecting 1 platform.

Because that's the right thing to do. Small hacks are nice, but when 
they accumulate (and they always do over time) then maintainability 
suffers. This is why you may do whatever small hacks in your own copy of 
the kernel code and that might be good enough, but the mainline source 
tree should be held to higher standards.

> There are probably plenty of kernel config options that you could enable
> that would break any number of systems.

That's no excuse to add more of them. Many people are constantly working 
to move things in the other direction.

> So, why do we feel that XIP_KERNEL needs a warm safety blanket around 
> it?

Because we simply try not to create invalid kernel configurations. 
XIP_KERNEL is not more special than other symbols in that respect.

And if the kconfig language has to be extended for proper configurations 
to be produced then that's what it is, and trying to cheat around that 
fact won't produce any good.


Nicolas

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

On Friday, June 22, 2018, Nicolas Pitre wrote:
> > So, why do we feel that XIP_KERNEL needs a warm safety blanket around
> > it?
> 
> Because we simply try not to create invalid kernel configurations.
> XIP_KERNEL is not more special than other symbols in that respect.

Then here's a question.

To be clear, the discussion is around

  "Being able to build a kernel that will not boot"

So which one of these is more important: build or boot?

Meaning what if you can select multiple platforms in kconfig, but then 
there is a .c file that does more sanity checking that then prevents the 
full build using a #error.

In that case you can never "build" a kernel that has no chance of 
booting on all the selected platforms.

There are configs options today that you can select, but unless some 
external criteria is  met during build time, the build will fail (like
with a "missing .h file" message or something)


Chris

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Nicolas Pitre]

On Fri, 22 Jun 2018, Chris Brandt wrote:

> On Friday, June 22, 2018, Nicolas Pitre wrote:
> > > So, why do we feel that XIP_KERNEL needs a warm safety blanket around
> > > it?
> > 
> > Because we simply try not to create invalid kernel configurations.
> > XIP_KERNEL is not more special than other symbols in that respect.
> 
> Then here's a question.
> 
> To be clear, the discussion is around
> 
>   "Being able to build a kernel that will not boot"
> 
> So which one of these is more important: build or boot?

Obviously both. Most people are ultimately interested in kernels that 
can boot.

> Meaning what if you can select multiple platforms in kconfig, but then 
> there is a .c file that does more sanity checking that then prevents the 
> full build using a #error.

Sorry, that is still cheating around the actual issue, which is the 
inability to properly express mutually exclusive config symbols in 
kconfig.


Nicolas

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 05:23:09PM +0000, Chris Brandt wrote:
> Then here's a question.
> 
> To be clear, the discussion is around
> 
>   "Being able to build a kernel that will not boot"
> 
> So which one of these is more important: build or boot?

We care about both.

> Meaning what if you can select multiple platforms in kconfig, but then 
> there is a .c file that does more sanity checking that then prevents the 
> full build using a #error.

... which is not acceptable.  We have a lot of automated build
infrastructure to build almost every commit in the mainline kernel
against almost every build configuration that is present in the
kernel and every architecture that is present in the mainline kernel.
We also have people that build random configurations and fix any
build failures and warnings which result from that.

I also build randconfigs here.

> In that case you can never "build" a kernel that has no chance of 
> booting on all the selected platforms.
> 
> There are configs options today that you can select, but unless some 
> external criteria is  met during build time, the build will fail (like
> with a "missing .h file" message or something)

Such as?  I don't think that's found by the randconfig builders - I've
never noticed any such failures on ARM.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Chris Brandt]

On Friday, June 22, 2018, Russell King - ARM Linux wrote:
> > There are configs options today that you can select, but unless some
> > external criteria is  met during build time, the build will fail (like
> > with a "missing .h file" message or something)
> 
> Such as?  I don't think that's found by the randconfig builders - I've
> never noticed any such failures on ARM.

I got this set once by accident after a kernel update

   CONFIG_SYSTEM_TRUSTED_KEYRING=y

which then let me to this error:

  HOSTCC  scripts/extract-cert
../scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
compilation terminated.



Regardless, I take your opinion as valid.


Chris

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Geert Uytterhoeven]

Hi Chris,

On Fri, Jun 22, 2018 at 10:25 PM Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Friday, June 22, 2018, Russell King - ARM Linux wrote:
> > > There are configs options today that you can select, but unless some
> > > external criteria is  met during build time, the build will fail (like
> > > with a "missing .h file" message or something)
> >
> > Such as?  I don't think that's found by the randconfig builders - I've
> > never noticed any such failures on ARM.
>
> I got this set once by accident after a kernel update
>
>    CONFIG_SYSTEM_TRUSTED_KEYRING=y
>
> which then let me to this error:
>
>   HOSTCC  scripts/extract-cert
> ../scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
> compilation terminated.

Which just means libssl-dev became a build dependency.

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

Re: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

[Russell King - ARM Linux]

On Fri, Jun 22, 2018 at 08:25:06PM +0000, Chris Brandt wrote:
> On Friday, June 22, 2018, Russell King - ARM Linux wrote:
> > > There are configs options today that you can select, but unless some
> > > external criteria is  met during build time, the build will fail (like
> > > with a "missing .h file" message or something)
> > 
> > Such as?  I don't think that's found by the randconfig builders - I've
> > never noticed any such failures on ARM.
> 
> I got this set once by accident after a kernel update
> 
>    CONFIG_SYSTEM_TRUSTED_KEYRING=y
> 
> which then let me to this error:
> 
>   HOSTCC  scripts/extract-cert
> ../scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
> compilation terminated.

Hmm.  Is that a problem if the documented minimum requirements to build
the kernel are violated?  It seems the openssl 1.0.0 development package
is required to build kernels v4.3 and beyond.

Here's what Documentation/process/changes.rst has to say about it:

Current Minimal Requirements
****************************
...
====================== ===============  ========================================
        Program        Minimal version       Command to check the version
====================== ===============  ========================================
openssl & libcrypto    1.0.0            openssl version
...
OpenSSL
-------

Module signing and external certificate handling use the OpenSSL program and
crypto library to do key creation and signature generation.

You will need openssl to build kernels 3.7 and higher if module signing is
enabled.  You will also need openssl development packages to build kernels 4.3
and higher.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up