[PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Geert Uytterhoeven]

As upstream Linux does not support XIP, it cannot run in 8 MiB of
HyperRAM.  Hence the 64 MiB of SDRAM on the sub-board needs to be
enabled, which has the following ramifications:
  - SCIF4 connected to the on-board USB-serial can no longer be used as
    the serial console,
  - Instead, SCIF2 is used as the serial console, by connecting a 3.3V
    TTL USB-to-Serial adapter to the CMOS camera connector,
  - The first Ethernet channel can no longer be used,
  - USB Channel 1 loses the overcurrent input signal.

Based on the Linux-4.19 BSP for RZ/A2.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
This depends on commit 91e4f3d37e1a9323 ("ARM: 8972/1: boot: Obtain
start of physical memory from DTB") in linux-arm/for-next.
Hence I cannot queue this in renesas-devel before v5.8-rc1.
---
 arch/arm/boot/dts/r7s9210-rza2mevb.dts | 53 +++++++++++++++-----------
 1 file changed, 31 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/r7s9210-rza2mevb.dts b/arch/arm/boot/dts/r7s9210-rza2mevb.dts
index 0686bac4bfd8e191..d719c3a133a966fb 100644
--- a/arch/arm/boot/dts/r7s9210-rza2mevb.dts
+++ b/arch/arm/boot/dts/r7s9210-rza2mevb.dts
@@ -4,6 +4,28 @@
  *
  * Copyright (C) 2018 Renesas Electronics
  *
+ * As upstream Linux does not support XIP, it cannot run in 8 MiB of HyperRAM.
+ * Hence the 64 MiB of SDRAM on the sub-board needs to be enabled, which has
+ * the following ramifications:
+ *   - SCIF4 connected to the on-board USB-serial can no longer be used as the
+ *     serial console,
+ *   - Instead, SCIF2 is used as the serial console, by connecting a 3.3V TTL
+ *     USB-to-Serial adapter to the CMOS camera connector:
+ *       - RXD = CN17-9,
+ *       - TXD = CN17-10,
+ *       - GND = CN17-2 or CN17-17,
+ *   - The first Ethernet channel can no longer be used,
+ *   - USB Channel 1 loses the overcurrent input signal.
+ *
+ * Please make sure your sub-board matches the following switch settings:
+ *
+ *           SW6                SW6-1 set to SDRAM
+ *  ON                          SW6-2 set to Audio
+ * +---------------------+      SW6-3 set to DRP
+ * | =   =   = = =       |      SW6-4 set to CEU
+ * |   =   =             |      SW6-5 set to Ether2
+ * | 1 2 3 4 5 6 7 8 9 0 |      SW6-6 set to VDC6
+ * +---------------------+      SW6-7 set to VDC6
  */
 
 /dts-v1/;
@@ -17,8 +39,7 @@
 	compatible = "renesas,rza2mevb", "renesas,r7s9210";
 
 	aliases {
-		serial0 = &scif4;
-		ethernet0 = &ether0;
+		serial0 = &scif2;
 		ethernet1 = &ether1;
 	};
 
@@ -58,9 +79,9 @@
 		};
 	};
 
-	memory@40000000 {
+	memory@c000000 {
 		device_type = "memory";
-		reg = <0x40000000 0x00800000>;	 /* HyperRAM */
+		reg = <0x0c000000 0x04000000>;	/* SDRAM */
 	};
 };
 
@@ -72,17 +93,6 @@
 	status = "okay";
 };
 
-&ether0 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&eth0_pins>;
-	status = "okay";
-	renesas,no-ether-link;
-	phy-handle = <&phy0>;
-	phy0: ethernet-phy@0 {
-		reg = <0>;
-	};
-};
-
 &ether1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&eth1_pins>;
@@ -142,9 +152,9 @@
 	};
 
 	/* Serial Console */
-	scif4_pins: serial4 {
-		pinmux = <RZA2_PINMUX(PORT9, 0, 4)>,	/* TxD4 */
-			 <RZA2_PINMUX(PORT9, 1, 4)>;	/* RxD4 */
+	scif2_pins: serial2 {
+		pinmux = <RZA2_PINMUX(PORTE, 2, 3)>,	/* TxD2 */
+			 <RZA2_PINMUX(PORTE, 1, 3)>;	/* RxD2 */
 	};
 
 	sdhi0_pins: sdhi0 {
@@ -165,8 +175,7 @@
 
 	usb1_pins: usb1 {
 		pinmux = <RZA2_PINMUX(PORTC, 0, 1)>,	/* VBUSIN1 */
-			 <RZA2_PINMUX(PORTC, 5, 1)>,	/* VBUSEN1 */
-			 <RZA2_PINMUX(PORT7, 5, 5)>;	/* OVRCUR1 */
+			 <RZA2_PINMUX(PORTC, 5, 1)>;	/* VBUSEN1 */
 	};
 };
 
@@ -176,9 +185,9 @@
 };
 
 /* Serial Console */
-&scif4 {
+&scif2 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&scif4_pins>;
+	pinctrl-0 = <&scif2_pins>;
 
 	status = "okay";
 };
-- 
2.17.1

[PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Geert Uytterhoeven]

As upstream Linux does not support XIP, it cannot run in 8 MiB of
HyperRAM.  Hence the 64 MiB of SDRAM on the sub-board needs to be
enabled, which has the following ramifications:
  - SCIF4 connected to the on-board USB-serial can no longer be used as
    the serial console,
  - Instead, SCIF2 is used as the serial console, by connecting a 3.3V
    TTL USB-to-Serial adapter to the CMOS camera connector,
  - The first Ethernet channel can no longer be used,
  - USB Channel 1 loses the overcurrent input signal.

Based on the Linux-4.19 BSP for RZ/A2.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
This depends on commit 91e4f3d37e1a9323 ("ARM: 8972/1: boot: Obtain
start of physical memory from DTB") in linux-arm/for-next.
Hence I cannot queue this in renesas-devel before v5.8-rc1.
---
 arch/arm/boot/dts/r7s9210-rza2mevb.dts | 53 +++++++++++++++-----------
 1 file changed, 31 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/r7s9210-rza2mevb.dts b/arch/arm/boot/dts/r7s9210-rza2mevb.dts
index 0686bac4bfd8e191..d719c3a133a966fb 100644
--- a/arch/arm/boot/dts/r7s9210-rza2mevb.dts
+++ b/arch/arm/boot/dts/r7s9210-rza2mevb.dts
@@ -4,6 +4,28 @@
  *
  * Copyright (C) 2018 Renesas Electronics
  *
+ * As upstream Linux does not support XIP, it cannot run in 8 MiB of HyperRAM.
+ * Hence the 64 MiB of SDRAM on the sub-board needs to be enabled, which has
+ * the following ramifications:
+ *   - SCIF4 connected to the on-board USB-serial can no longer be used as the
+ *     serial console,
+ *   - Instead, SCIF2 is used as the serial console, by connecting a 3.3V TTL
+ *     USB-to-Serial adapter to the CMOS camera connector:
+ *       - RXD = CN17-9,
+ *       - TXD = CN17-10,
+ *       - GND = CN17-2 or CN17-17,
+ *   - The first Ethernet channel can no longer be used,
+ *   - USB Channel 1 loses the overcurrent input signal.
+ *
+ * Please make sure your sub-board matches the following switch settings:
+ *
+ *           SW6                SW6-1 set to SDRAM
+ *  ON                          SW6-2 set to Audio
+ * +---------------------+      SW6-3 set to DRP
+ * | =   =   = = =       |      SW6-4 set to CEU
+ * |   =   =             |      SW6-5 set to Ether2
+ * | 1 2 3 4 5 6 7 8 9 0 |      SW6-6 set to VDC6
+ * +---------------------+      SW6-7 set to VDC6
  */
 
 /dts-v1/;
@@ -17,8 +39,7 @@
 	compatible = "renesas,rza2mevb", "renesas,r7s9210";
 
 	aliases {
-		serial0 = &scif4;
-		ethernet0 = &ether0;
+		serial0 = &scif2;
 		ethernet1 = &ether1;
 	};
 
@@ -58,9 +79,9 @@
 		};
 	};
 
-	memory@40000000 {
+	memory@c000000 {
 		device_type = "memory";
-		reg = <0x40000000 0x00800000>;	 /* HyperRAM */
+		reg = <0x0c000000 0x04000000>;	/* SDRAM */
 	};
 };
 
@@ -72,17 +93,6 @@
 	status = "okay";
 };
 
-&ether0 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&eth0_pins>;
-	status = "okay";
-	renesas,no-ether-link;
-	phy-handle = <&phy0>;
-	phy0: ethernet-phy@0 {
-		reg = <0>;
-	};
-};
-
 &ether1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&eth1_pins>;
@@ -142,9 +152,9 @@
 	};
 
 	/* Serial Console */
-	scif4_pins: serial4 {
-		pinmux = <RZA2_PINMUX(PORT9, 0, 4)>,	/* TxD4 */
-			 <RZA2_PINMUX(PORT9, 1, 4)>;	/* RxD4 */
+	scif2_pins: serial2 {
+		pinmux = <RZA2_PINMUX(PORTE, 2, 3)>,	/* TxD2 */
+			 <RZA2_PINMUX(PORTE, 1, 3)>;	/* RxD2 */
 	};
 
 	sdhi0_pins: sdhi0 {
@@ -165,8 +175,7 @@
 
 	usb1_pins: usb1 {
 		pinmux = <RZA2_PINMUX(PORTC, 0, 1)>,	/* VBUSIN1 */
-			 <RZA2_PINMUX(PORTC, 5, 1)>,	/* VBUSEN1 */
-			 <RZA2_PINMUX(PORT7, 5, 5)>;	/* OVRCUR1 */
+			 <RZA2_PINMUX(PORTC, 5, 1)>;	/* VBUSEN1 */
 	};
 };
 
@@ -176,9 +185,9 @@
 };
 
 /* Serial Console */
-&scif4 {
+&scif2 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&scif4_pins>;
+	pinctrl-0 = <&scif2_pins>;
 
 	status = "okay";
 };
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Nicolas Pitre]

On Thu, 7 May 2020, Geert Uytterhoeven wrote:

> As upstream Linux does not support XIP,

What?


Nicolas

Re: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Nicolas Pitre]

On Thu, 7 May 2020, Geert Uytterhoeven wrote:

> As upstream Linux does not support XIP,

What?


Nicolas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Geert Uytterhoeven]

Hi Nicolas,

On Thu, May 7, 2020 at 4:58 PM Nicolas Pitre <nico@fluxnic.net> wrote:
> On Thu, 7 May 2020, Geert Uytterhoeven wrote:
>
> > As upstream Linux does not support XIP,
>
> What?

Not for an ARM v7 platform:

    config XIP_KERNEL
            bool "Kernel Execute-In-Place from ROM"
            depends on !ARM_LPAE && !ARCH_MULTIPLATFORM

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: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Geert Uytterhoeven]

Hi Nicolas,

On Thu, May 7, 2020 at 4:58 PM Nicolas Pitre <nico@fluxnic.net> wrote:
> On Thu, 7 May 2020, Geert Uytterhoeven wrote:
>
> > As upstream Linux does not support XIP,
>
> What?

Not for an ARM v7 platform:

    config XIP_KERNEL
            bool "Kernel Execute-In-Place from ROM"
            depends on !ARM_LPAE && !ARCH_MULTIPLATFORM

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Nicolas Pitre]

On Thu, 7 May 2020, Geert Uytterhoeven wrote:

> Hi Nicolas,
> 
> On Thu, May 7, 2020 at 4:58 PM Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Thu, 7 May 2020, Geert Uytterhoeven wrote:
> >
> > > As upstream Linux does not support XIP,
> >
> > What?
> 
> Not for an ARM v7 platform:
> 
>     config XIP_KERNEL
>             bool "Kernel Execute-In-Place from ROM"
>             depends on !ARM_LPAE && !ARCH_MULTIPLATFORM

Of course this is an artificial limitation.

You can have XIP on ARMv7 if you want. It requires some kconfig 
tweaks though.


Nicolas

Re: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Nicolas Pitre]

On Thu, 7 May 2020, Geert Uytterhoeven wrote:

> Hi Nicolas,
> 
> On Thu, May 7, 2020 at 4:58 PM Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Thu, 7 May 2020, Geert Uytterhoeven wrote:
> >
> > > As upstream Linux does not support XIP,
> >
> > What?
> 
> Not for an ARM v7 platform:
> 
>     config XIP_KERNEL
>             bool "Kernel Execute-In-Place from ROM"
>             depends on !ARM_LPAE && !ARCH_MULTIPLATFORM

Of course this is an artificial limitation.

You can have XIP on ARMv7 if you want. It requires some kconfig 
tweaks though.


Nicolas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Geert Uytterhoeven]

""
Hi Nicolas,

On Thu, May 7, 2020 at 7:07 PM Nicolas Pitre <nico@fluxnic.net> wrote:
> On Thu, 7 May 2020, Geert Uytterhoeven wrote:
> > On Thu, May 7, 2020 at 4:58 PM Nicolas Pitre <nico@fluxnic.net> wrote:
> > > On Thu, 7 May 2020, Geert Uytterhoeven wrote:
> > > > As upstream Linux does not support XIP,
> > >
> > > What?
> >
> > Not for an ARM v7 platform:
> >
> >     config XIP_KERNEL
> >             bool "Kernel Execute-In-Place from ROM"
> >             depends on !ARM_LPAE && !ARCH_MULTIPLATFORM
>
> Of course this is an artificial limitation.
>
> You can have XIP on ARMv7 if you want. It requires some kconfig
> tweaks though.

I am happy to hear that!
Do you have any guidance how to implement that?
So far our tries have failed.

"[PATCH 0/2] ARM: ARMv7 (with MMU) XIP without ARCH_MULTIPLATFORM"
http://lore.kernel.org/r/20170209033044.19513-1-chris.brandt@renesas.com
"[PATCH] ARM: Allow MULTIPLATFOR to select XIP
https://lore.kernel.org/linux-arm-kernel/1455816310-11308-1-git-send-email-chris.brandt@renesas.com/
"[PATCH 0/2] ARM: xip: Get XIP for ARMv7 working again
http://lore.kernel.org/r/1437057434-1616-1-git-send-email-chris.brandt@renesas.com
"XIP_KERNEL and !ARCH_MULTIPLATFORM
http://lore.kernel.org/r/HK2PR06MB0561CC16649A9C1F341CC6648A030@HK2PR06MB0561.apcprd06.prod.outlook.com
...

Thanks, and have a nice weekend

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: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Geert Uytterhoeven]

""
Hi Nicolas,

On Thu, May 7, 2020 at 7:07 PM Nicolas Pitre <nico@fluxnic.net> wrote:
> On Thu, 7 May 2020, Geert Uytterhoeven wrote:
> > On Thu, May 7, 2020 at 4:58 PM Nicolas Pitre <nico@fluxnic.net> wrote:
> > > On Thu, 7 May 2020, Geert Uytterhoeven wrote:
> > > > As upstream Linux does not support XIP,
> > >
> > > What?
> >
> > Not for an ARM v7 platform:
> >
> >     config XIP_KERNEL
> >             bool "Kernel Execute-In-Place from ROM"
> >             depends on !ARM_LPAE && !ARCH_MULTIPLATFORM
>
> Of course this is an artificial limitation.
>
> You can have XIP on ARMv7 if you want. It requires some kconfig
> tweaks though.

I am happy to hear that!
Do you have any guidance how to implement that?
So far our tries have failed.

"[PATCH 0/2] ARM: ARMv7 (with MMU) XIP without ARCH_MULTIPLATFORM"
http://lore.kernel.org/r/20170209033044.19513-1-chris.brandt@renesas.com
"[PATCH] ARM: Allow MULTIPLATFOR to select XIP
https://lore.kernel.org/linux-arm-kernel/1455816310-11308-1-git-send-email-chris.brandt@renesas.com/
"[PATCH 0/2] ARM: xip: Get XIP for ARMv7 working again
http://lore.kernel.org/r/1437057434-1616-1-git-send-email-chris.brandt@renesas.com
"XIP_KERNEL and !ARCH_MULTIPLATFORM
http://lore.kernel.org/r/HK2PR06MB0561CC16649A9C1F341CC6648A030@HK2PR06MB0561.apcprd06.prod.outlook.com
...

Thanks, and have a nice weekend

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Chris Brandt]

Hi Geert and Nicolas,

On Fri, May 8, 2020, Geert Uytterhoeven wrote:
> Do you have any guidance how to implement that?
> So far our tries have failed.

Ahh....A nice history of my failed attempts    :o

The big argument was always that "XIP cannot be multi-platform by 
definition because RAM/ROM always resides at different addresses in different 
devices". And as you know, the physical address for RAM and ROM have to 
be hard coded in the kernel binary.

At an ELC a while back, I talked to Arnd and his suggestion was to put 
the base addresses for RAM and ROM at a fixed location in the kernel 
binary. Then for each SoC, you manually modify those values in the each 
binary to match your board. This means there is 'technically' a single build
that will support all boards.

I admit, while it sounded reasonable, I never tried it. Mostly because 
it seemed like a lot of work just to send a patch that might get 
instantly NAK-ed.


Chris

RE: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Chris Brandt]

Hi Geert and Nicolas,

On Fri, May 8, 2020, Geert Uytterhoeven wrote:
> Do you have any guidance how to implement that?
> So far our tries have failed.

Ahh....A nice history of my failed attempts    :o

The big argument was always that "XIP cannot be multi-platform by 
definition because RAM/ROM always resides at different addresses in different 
devices". And as you know, the physical address for RAM and ROM have to 
be hard coded in the kernel binary.

At an ELC a while back, I talked to Arnd and his suggestion was to put 
the base addresses for RAM and ROM at a fixed location in the kernel 
binary. Then for each SoC, you manually modify those values in the each 
binary to match your board. This means there is 'technically' a single build
that will support all boards.

I admit, while it sounded reasonable, I never tried it. Mostly because 
it seemed like a lot of work just to send a patch that might get 
instantly NAK-ed.


Chris
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Nicolas Pitre]

On Fri, 8 May 2020, Chris Brandt wrote:

> The big argument was always that "XIP cannot be multi-platform by 
> definition because RAM/ROM always resides at different addresses in different 
> devices". And as you know, the physical address for RAM and ROM have to 
> be hard coded in the kernel binary.

Exact.  So what is the problem?

> At an ELC a while back, I talked to Arnd and his suggestion was to put 
> the base addresses for RAM and ROM at a fixed location in the kernel 
> binary. Then for each SoC, you manually modify those values in the each 
> binary to match your board. This means there is 'technically' a single build
> that will support all boards.

The very reason for using XIP in the first place is to maximize resource 
savings on constrained platforms. Any notion of a multi-platform kernel 
is completely contrary to this goal. This is even more true for no-MMU 
platforms where you can't abstract physical address differences behind a 
page table.

Multi-platform kernel supporting all boards make sense for generic 
distros and/or build coverage tests. But a multi-platform XIP kernel is 
a nonsense. Trying to make XIP multi-platform might be a nice 
intellectual challenge but that has zero value for actual deployment and 
usage.

Given that there isn't a lot of such platforms anyway, it should be 
possible to carry a few kconfig entries outside of the multi-platform 
menu for XIP targets and live with possible kconfig duplicates. That 
shouldn't be such a maintenance burden.


Nicolas

RE: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Nicolas Pitre]

On Fri, 8 May 2020, Chris Brandt wrote:

> The big argument was always that "XIP cannot be multi-platform by 
> definition because RAM/ROM always resides at different addresses in different 
> devices". And as you know, the physical address for RAM and ROM have to 
> be hard coded in the kernel binary.

Exact.  So what is the problem?

> At an ELC a while back, I talked to Arnd and his suggestion was to put 
> the base addresses for RAM and ROM at a fixed location in the kernel 
> binary. Then for each SoC, you manually modify those values in the each 
> binary to match your board. This means there is 'technically' a single build
> that will support all boards.

The very reason for using XIP in the first place is to maximize resource 
savings on constrained platforms. Any notion of a multi-platform kernel 
is completely contrary to this goal. This is even more true for no-MMU 
platforms where you can't abstract physical address differences behind a 
page table.

Multi-platform kernel supporting all boards make sense for generic 
distros and/or build coverage tests. But a multi-platform XIP kernel is 
a nonsense. Trying to make XIP multi-platform might be a nice 
intellectual challenge but that has zero value for actual deployment and 
usage.

Given that there isn't a lot of such platforms anyway, it should be 
possible to carry a few kconfig entries outside of the multi-platform 
menu for XIP targets and live with possible kconfig duplicates. That 
shouldn't be such a maintenance burden.


Nicolas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Geert Uytterhoeven]

Hi Nicolas,

On Fri, May 8, 2020 at 4:41 PM Nicolas Pitre <nico@fluxnic.net> wrote:
> On Fri, 8 May 2020, Chris Brandt wrote:
> > The big argument was always that "XIP cannot be multi-platform by
> > definition because RAM/ROM always resides at different addresses in different
> > devices". And as you know, the physical address for RAM and ROM have to
> > be hard coded in the kernel binary.
>
> Exact.  So what is the problem?

Ah, you've fallen for the "multi-platform" fallacy! I have no desire to
enable support for multiple platforms in a single kernel that supports
XIP on all platforms.
I merely want it to be possible to build a XIP kernel for one platform.
As ARM v7m systems must be part of the ARCH_MULTI_V7 gang, they cannot
enable the XIP_KERNEL config symbol.

[PATCH] [RFC] arm: Replace "multiple platforms" by "common platform"
http://lore.kernel.org/r/20180621155906.12821-1-geert+renesas@glider.be

> > At an ELC a while back, I talked to Arnd and his suggestion was to put
> > the base addresses for RAM and ROM at a fixed location in the kernel
> > binary. Then for each SoC, you manually modify those values in the each
> > binary to match your board. This means there is 'technically' a single build
> > that will support all boards.

Interesting. I didn't know that suggestion.
Sounds doable (but see below).

> The very reason for using XIP in the first place is to maximize resource
> savings on constrained platforms. Any notion of a multi-platform kernel
> is completely contrary to this goal. This is even more true for no-MMU
> platforms where you can't abstract physical address differences behind a
> page table.
>
> Multi-platform kernel supporting all boards make sense for generic
> distros and/or build coverage tests. But a multi-platform XIP kernel is
> a nonsense. Trying to make XIP multi-platform might be a nice
> intellectual challenge but that has zero value for actual deployment and
> usage.

Agreed.

> Given that there isn't a lot of such platforms anyway, it should be
> possible to carry a few kconfig entries outside of the multi-platform
> menu for XIP targets and live with possible kconfig duplicates. That
> shouldn't be such a maintenance burden.

Still, it's duplication, which could be avoided using a single "know
what you're doing" Kconfig option.
And it will grow, as XIP could be used on lots of platforms.

I believe this is exactly what Chris' last attempt did?


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: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Geert Uytterhoeven]

Hi Nicolas,

On Fri, May 8, 2020 at 4:41 PM Nicolas Pitre <nico@fluxnic.net> wrote:
> On Fri, 8 May 2020, Chris Brandt wrote:
> > The big argument was always that "XIP cannot be multi-platform by
> > definition because RAM/ROM always resides at different addresses in different
> > devices". And as you know, the physical address for RAM and ROM have to
> > be hard coded in the kernel binary.
>
> Exact.  So what is the problem?

Ah, you've fallen for the "multi-platform" fallacy! I have no desire to
enable support for multiple platforms in a single kernel that supports
XIP on all platforms.
I merely want it to be possible to build a XIP kernel for one platform.
As ARM v7m systems must be part of the ARCH_MULTI_V7 gang, they cannot
enable the XIP_KERNEL config symbol.

[PATCH] [RFC] arm: Replace "multiple platforms" by "common platform"
http://lore.kernel.org/r/20180621155906.12821-1-geert+renesas@glider.be

> > At an ELC a while back, I talked to Arnd and his suggestion was to put
> > the base addresses for RAM and ROM at a fixed location in the kernel
> > binary. Then for each SoC, you manually modify those values in the each
> > binary to match your board. This means there is 'technically' a single build
> > that will support all boards.

Interesting. I didn't know that suggestion.
Sounds doable (but see below).

> The very reason for using XIP in the first place is to maximize resource
> savings on constrained platforms. Any notion of a multi-platform kernel
> is completely contrary to this goal. This is even more true for no-MMU
> platforms where you can't abstract physical address differences behind a
> page table.
>
> Multi-platform kernel supporting all boards make sense for generic
> distros and/or build coverage tests. But a multi-platform XIP kernel is
> a nonsense. Trying to make XIP multi-platform might be a nice
> intellectual challenge but that has zero value for actual deployment and
> usage.

Agreed.

> Given that there isn't a lot of such platforms anyway, it should be
> possible to carry a few kconfig entries outside of the multi-platform
> menu for XIP targets and live with possible kconfig duplicates. That
> shouldn't be such a maintenance burden.

Still, it's duplication, which could be avoided using a single "know
what you're doing" Kconfig option.
And it will grow, as XIP could be used on lots of platforms.

I believe this is exactly what Chris' last attempt did?


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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Nicolas Pitre]

On Fri, 8 May 2020, Geert Uytterhoeven wrote:

> Hi Nicolas,
> 
> On Fri, May 8, 2020 at 4:41 PM Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Fri, 8 May 2020, Chris Brandt wrote:
> > > The big argument was always that "XIP cannot be multi-platform by
> > > definition because RAM/ROM always resides at different addresses in different
> > > devices". And as you know, the physical address for RAM and ROM have to
> > > be hard coded in the kernel binary.
> >
> > Exact.  So what is the problem?
> 
> Ah, you've fallen for the "multi-platform" fallacy!

Me?!  You must be mistaken on the person.

> I have no desire to enable support for multiple platforms in a single 
> kernel that supports XIP on all platforms.

Absolutely!  As I just said in my previous email, multi-platform XIP 
kernels are non-sense.


Nicolas

Re: [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM

[Nicolas Pitre]

On Fri, 8 May 2020, Geert Uytterhoeven wrote:

> Hi Nicolas,
> 
> On Fri, May 8, 2020 at 4:41 PM Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Fri, 8 May 2020, Chris Brandt wrote:
> > > The big argument was always that "XIP cannot be multi-platform by
> > > definition because RAM/ROM always resides at different addresses in different
> > > devices". And as you know, the physical address for RAM and ROM have to
> > > be hard coded in the kernel binary.
> >
> > Exact.  So what is the problem?
> 
> Ah, you've fallen for the "multi-platform" fallacy!

Me?!  You must be mistaken on the person.

> I have no desire to enable support for multiple platforms in a single 
> kernel that supports XIP on all platforms.

Absolutely!  As I just said in my previous email, multi-platform XIP 
kernels are non-sense.


Nicolas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel