| Message ID | 20200507080528.547-1-geert+renesas@glider.be (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [PATCH/RFC] ARM: dts: rza2mevb: Upstream Linux requires SDRAM | expand |
On Thu, 7 May 2020, Geert Uytterhoeven wrote:
> As upstream Linux does not support XIP,
What?
Nicolas
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
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
"" 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
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
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
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
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
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 = ðer0; + serial0 = &scif2; ethernet1 = ðer1; }; @@ -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"; }; -ðer0 { - pinctrl-names = "default"; - pinctrl-0 = <ð0_pins>; - status = "okay"; - renesas,no-ether-link; - phy-handle = <&phy0>; - phy0: ethernet-phy@0 { - reg = <0>; - }; -}; - ðer1 { pinctrl-names = "default"; pinctrl-0 = <ð1_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"; };
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(-)