| Message ID | 20190809162956.488941-1-arnd@arndb.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | ARM: preparation for multiplatform iop32x | expand |
On Fri, Aug 09, 2019 at 06:29:41PM +0200, Arnd Bergmann wrote: > I'm looking into converting some of the remaining ARMv5 > platforms in arch/arm/ to work together in a single kernel > binary. > > IOP32x seems to be a fairly easy target for multiplatform > by itself, but the way the plat-iop code interacts with > three generations of the code, and how the dma-adma driver > is configured at compile-time for each version gets in the > way. > > I considered adding more indirection layers for those two, > but removing iop33x and iop13xx is much easier in comparison, > so this is the first approach I'm posting. > > If we conclude that iop33x and iop13xx are indeed not used > any more, the remaining patches in this series are > straightforward. The actual multiplatform conversion also > requires changes to the irqchip driver that are not completely > mechanic, and we can discuss those after deciding what to do > with the first set. > > Adding a few people to Cc that historically worked on IOP. I haven't worked with any of these platforms for many years now, and I can't really say much about their current use.
On Fri, Aug 09, 2019 at 06:33:15PM +0200, Arnd Bergmann wrote: > There are three families of IOP machines we support in Linux: iop32x > (which includes EP80219), iop33x and iop13xx (aka IOP34x aka WP8134x). > > All products we support in the kernel are based on the first of these, > iop32x, the other families only ever supported the Intel reference > boards but no actual machine anyone could ever buy. > > While one could clearly make them all three work in a single kernel > with some work, this takes the easy way out, removing the later two > platforms entirely, under the assumption that there are no remaining > users. > > Earlier versions of OpenWRT and Debian both had support for iop32x > but not the others, and they both dropped iop32x as well in their 2015 > releases. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Wolfram Sang <wsa@the-dreams.de> # for I2C parts
[ add Martin (if cyrius.com address is still valid) ] On Fri, Aug 9, 2019 at 9:35 AM Arnd Bergmann <arnd@arndb.de> wrote: > > There are three families of IOP machines we support in Linux: iop32x > (which includes EP80219), iop33x and iop13xx (aka IOP34x aka WP8134x). > > All products we support in the kernel are based on the first of these, > iop32x, the other families only ever supported the Intel reference > boards but no actual machine anyone could ever buy. > > While one could clearly make them all three work in a single kernel > with some work, this takes the easy way out, removing the later two > platforms entirely, under the assumption that there are no remaining > users. > > Earlier versions of OpenWRT and Debian both had support for iop32x > but not the others, and they both dropped iop32x as well in their 2015 > releases. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > I'm just guessing that iop32x is still needed, and the other two are > not. If anyone disagrees with that assessment, let me know so we > can come up with an alternative approach. I'm not sure who would scream if iop32x support went away as well, but I have not followed this space in years hence copying Martin. In any event: Acked-by: Dan Williams <dan.j.williams@intel.com>
On Fri, Aug 09, 2019 at 11:34:12AM -0700, Dan Williams wrote: > [ add Martin (if cyrius.com address is still valid) ] > > On Fri, Aug 9, 2019 at 9:35 AM Arnd Bergmann <arnd@arndb.de> wrote: > > > > There are three families of IOP machines we support in Linux: iop32x > > (which includes EP80219), iop33x and iop13xx (aka IOP34x aka WP8134x). > > > > All products we support in the kernel are based on the first of these, > > iop32x, the other families only ever supported the Intel reference > > boards but no actual machine anyone could ever buy. > > > > While one could clearly make them all three work in a single kernel > > with some work, this takes the easy way out, removing the later two > > platforms entirely, under the assumption that there are no remaining > > users. > > > > Earlier versions of OpenWRT and Debian both had support for iop32x > > but not the others, and they both dropped iop32x as well in their 2015 > > releases. > > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > --- > > I'm just guessing that iop32x is still needed, and the other two are > > not. If anyone disagrees with that assessment, let me know so we > > can come up with an alternative approach. > > I'm not sure who would scream if iop32x support went away as well, but > I have not followed this space in years hence copying Martin. > > In any event: > > Acked-by: Dan Williams <dan.j.williams@intel.com> Those of us who have and still run Thecus N2100's, for example?
On Fri, Aug 9, 2019 at 11:37 AM Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > > On Fri, Aug 09, 2019 at 11:34:12AM -0700, Dan Williams wrote: > > [ add Martin (if cyrius.com address is still valid) ] > > > > On Fri, Aug 9, 2019 at 9:35 AM Arnd Bergmann <arnd@arndb.de> wrote: > > > > > > There are three families of IOP machines we support in Linux: iop32x > > > (which includes EP80219), iop33x and iop13xx (aka IOP34x aka WP8134x). > > > > > > All products we support in the kernel are based on the first of these, > > > iop32x, the other families only ever supported the Intel reference > > > boards but no actual machine anyone could ever buy. > > > > > > While one could clearly make them all three work in a single kernel > > > with some work, this takes the easy way out, removing the later two > > > platforms entirely, under the assumption that there are no remaining > > > users. > > > > > > Earlier versions of OpenWRT and Debian both had support for iop32x > > > but not the others, and they both dropped iop32x as well in their 2015 > > > releases. > > > > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > > --- > > > I'm just guessing that iop32x is still needed, and the other two are > > > not. If anyone disagrees with that assessment, let me know so we > > > can come up with an alternative approach. > > > > I'm not sure who would scream if iop32x support went away as well, but > > I have not followed this space in years hence copying Martin. > > > > In any event: > > > > Acked-by: Dan Williams <dan.j.williams@intel.com> > > Those of us who have and still run Thecus N2100's, for example? Nice! Good to hear.
* Dan Williams <dan.j.williams@intel.com> [2019-08-09 11:34]: > > Earlier versions of OpenWRT and Debian both had support for iop32x > > but not the others, and they both dropped iop32x as well in their 2015 > > releases. > > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > --- > > I'm just guessing that iop32x is still needed, and the other two are > > not. If anyone disagrees with that assessment, let me know so we > > can come up with an alternative approach. > > I'm not sure who would scream if iop32x support went away as well, but > I have not followed this space in years hence copying Martin. I believe iop13xx were mostly Intel dev boards. I'm not aware of any major devices based on iop33x. As Arnd points out, Debian used to have support for various iop32x devices. While Debian hasn't supported iop32x in a number of years, these devices are still usable and in use (RMK being a prime example). So I think it's safe to drop iop33x/iop13xx while retaining support for iop32x. As I was looking at my email archives, I saw an email from Peter Teichmann who was working on an iop33x based platform (around 2009) so I've copied him as well. > In any event: > > Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Martin Michlmayr <tbm@cyrius.com>
On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr <tbm@cyrius.com> wrote: > As Arnd points out, Debian used to have support for various iop32x > devices. While Debian hasn't supported iop32x in a number of years, > these devices are still usable and in use (RMK being a prime example). I suppose it could be a good idea to add support for iop32x to OpenWrt and/or OpenEmbedded, both of which support some pretty constrained systems. I am personally using these distributions to support elder ARM hardware these days. Just my €0.01 Linus Walleij
On Wed, Aug 14, 2019 at 10:36 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr <tbm@cyrius.com> wrote: > > > As Arnd points out, Debian used to have support for various iop32x > > devices. While Debian hasn't supported iop32x in a number of years, > > these devices are still usable and in use (RMK being a prime example). > > I suppose it could be a good idea to add support for iop32x to > OpenWrt and/or OpenEmbedded, both of which support some > pretty constrained systems. I am personally using these > distributions to support elder ARM hardware these days. OpenWRT also had support in the past and dropped it around the same time as Debian. The way I understand it, a couple of platforms including iop32x were moved out of the main openwrt source tree into https://github.com/openwrt/targets/ because there was little interest in keeping them running. The idea was that any remaining users could add that feed to get minimal support, but I'm not sure if would still work. In particular, iop33x appears to be based on linux-3.3 plus three patches that are no longer needed in mainline. Building a mainline kernel without those patches may or may not work. Arnd
On Fri, Aug 9, 2019 at 6:30 PM Arnd Bergmann <arnd@arndb.de> wrote: > > I'm looking into converting some of the remaining ARMv5 > platforms in arch/arm/ to work together in a single kernel > binary. > > IOP32x seems to be a fairly easy target for multiplatform > by itself, but the way the plat-iop code interacts with > three generations of the code, and how the dma-adma driver > is configured at compile-time for each version gets in the > way. > > I considered adding more indirection layers for those two, > but removing iop33x and iop13xx is much easier in comparison, > so this is the first approach I'm posting. > > If we conclude that iop33x and iop13xx are indeed not used > any more, the remaining patches in this series are > straightforward. The actual multiplatform conversion also > requires changes to the irqchip driver that are not completely > mechanic, and we can discuss those after deciding what to do > with the first set. > > Adding a few people to Cc that historically worked on IOP. I applied the IOP series to to the arm/soc branch now, thanks for the reviews! Arnd
Hi, On Wed, Aug 14, 2019 at 10:36:01AM +0200, Linus Walleij wrote: > On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr <tbm@cyrius.com> wrote: > > As Arnd points out, Debian used to have support for various iop32x > > devices. While Debian hasn't supported iop32x in a number of years, > > these devices are still usable and in use (RMK being a prime example). > > I suppose it could be a good idea to add support for iop32x to > OpenWrt and/or OpenEmbedded, both of which support some > pretty constrained systems. This platform is not really too constrained... E.g. on N2100 you have 512 MB RAM, SATA disks and gigabit ethernet. Not that different from mvebu that Debian currently (?) supports. Maybe with multiplatform they could support iop32x again. A.
On Fri, Aug 16, 2019 at 06:42:49PM +0300, Aaro Koskinen wrote: > Hi, > > On Wed, Aug 14, 2019 at 10:36:01AM +0200, Linus Walleij wrote: > > On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr <tbm@cyrius.com> wrote: > > > As Arnd points out, Debian used to have support for various iop32x > > > devices. While Debian hasn't supported iop32x in a number of years, > > > these devices are still usable and in use (RMK being a prime example). > > > > I suppose it could be a good idea to add support for iop32x to > > OpenWrt and/or OpenEmbedded, both of which support some > > pretty constrained systems. > > This platform is not really too constrained... E.g. on N2100 you have > 512 MB RAM, SATA disks and gigabit ethernet. Not that different from > mvebu that Debian currently (?) supports. Maybe with multiplatform they > could support iop32x again. Probably not. The kernel has a dividing line between ARMv5 and ARMv6 where it's not possible to multiplatform across that boundary, so you're already needing separate kernel images there. Secondly, armhf distros won't be compatible with ARMv5, and to make them compatible will make performance on armhf suffer - you have to stop using barriers, exclusive load/store and a few other things. You have to rely on the kuser page exported by the kernel (which is now optional as it's deemed to be a security issue for ROP attacks) for some things that such a userspace requires - such as NPTL support. Effectively, ARMv5 is an entirely separate userspace distro from armhf.
Hi, On Fri, Aug 16, 2019 at 04:58:33PM +0100, Russell King - ARM Linux admin wrote: > On Fri, Aug 16, 2019 at 06:42:49PM +0300, Aaro Koskinen wrote: > > On Wed, Aug 14, 2019 at 10:36:01AM +0200, Linus Walleij wrote: > > > On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr <tbm@cyrius.com> wrote: > > > > As Arnd points out, Debian used to have support for various iop32x > > > > devices. While Debian hasn't supported iop32x in a number of years, > > > > these devices are still usable and in use (RMK being a prime example). > > > > > > I suppose it could be a good idea to add support for iop32x to > > > OpenWrt and/or OpenEmbedded, both of which support some > > > pretty constrained systems. > > > > This platform is not really too constrained... E.g. on N2100 you have > > 512 MB RAM, SATA disks and gigabit ethernet. Not that different from > > mvebu that Debian currently (?) supports. Maybe with multiplatform they > > could support iop32x again. > > Probably not. The kernel has a dividing line between ARMv5 and ARMv6 > where it's not possible to multiplatform across that boundary, so > you're already needing separate kernel images there. > > Secondly, armhf distros won't be compatible with ARMv5, and to make > them compatible will make performance on armhf suffer - you have to > stop using barriers, exclusive load/store and a few other things. > You have to rely on the kuser page exported by the kernel (which is > now optional as it's deemed to be a security issue for ROP attacks) > for some things that such a userspace requires - such as NPTL support. > > Effectively, ARMv5 is an entirely separate userspace distro from armhf. I thought they still had armel for ARMv5 and mvebu (kirkwood). A.
I'm looking into converting some of the remaining ARMv5 platforms in arch/arm/ to work together in a single kernel binary. IOP32x seems to be a fairly easy target for multiplatform by itself, but the way the plat-iop code interacts with three generations of the code, and how the dma-adma driver is configured at compile-time for each version gets in the way. I considered adding more indirection layers for those two, but removing iop33x and iop13xx is much easier in comparison, so this is the first approach I'm posting. If we conclude that iop33x and iop13xx are indeed not used any more, the remaining patches in this series are straightforward. The actual multiplatform conversion also requires changes to the irqchip driver that are not completely mechanic, and we can discuss those after deciding what to do with the first set. Adding a few people to Cc that historically worked on IOP. Arnd Arnd Bergmann (7): [RFC] ARM: remove Intel iop33x and iop13xx support dma: iop-adma: include prefetch.h dma: iop-adma: use correct printk format strings dma: iop-adma: allow building without platform headers ARM: xscale: fix multi-cpu compilation ARM: iop32x: make mach/uncompress.h independent of mach/hardware.h ARM: iop32x: merge everything into mach-iop32x/ arch/arm/Kconfig | 30 - arch/arm/Kconfig.debug | 8 +- arch/arm/Makefile | 3 - arch/arm/configs/iop13xx_defconfig | 118 -- arch/arm/configs/iop33x_defconfig | 85 -- arch/arm/mach-iop13xx/Kconfig | 21 - arch/arm/mach-iop13xx/Makefile | 9 - arch/arm/mach-iop13xx/Makefile.boot | 4 - arch/arm/mach-iop13xx/include/mach/adma.h | 608 --------- .../mach-iop13xx/include/mach/entry-macro.S | 29 - arch/arm/mach-iop13xx/include/mach/hardware.h | 22 - arch/arm/mach-iop13xx/include/mach/iop13xx.h | 508 -------- arch/arm/mach-iop13xx/include/mach/iq81340.h | 29 - arch/arm/mach-iop13xx/include/mach/irqs.h | 195 --- arch/arm/mach-iop13xx/include/mach/time.h | 127 -- .../mach-iop13xx/include/mach/uncompress.h | 23 - arch/arm/mach-iop13xx/io.c | 77 -- arch/arm/mach-iop13xx/iq81340mc.c | 84 -- arch/arm/mach-iop13xx/iq81340sc.c | 86 -- arch/arm/mach-iop13xx/irq.c | 227 ---- arch/arm/mach-iop13xx/msi.c | 152 --- arch/arm/mach-iop13xx/msi.h | 12 - arch/arm/mach-iop13xx/pci.c | 1115 ----------------- arch/arm/mach-iop13xx/pci.h | 66 - arch/arm/mach-iop13xx/setup.c | 595 --------- arch/arm/mach-iop13xx/tpmi.c | 244 ---- arch/arm/mach-iop32x/Makefile | 10 +- arch/arm/{plat-iop => mach-iop32x}/adma.c | 39 +- arch/arm/{plat-iop => mach-iop32x}/cp6.c | 0 arch/arm/mach-iop32x/em7210.c | 5 +- arch/arm/mach-iop32x/glantank.c | 5 +- .../mach-iop32x/{include/mach => }/glantank.h | 2 - .../mach-iop32x/{include/mach => }/hardware.h | 6 +- arch/arm/{plat-iop => mach-iop32x}/i2c.c | 21 +- arch/arm/mach-iop32x/include/mach/adma.h | 6 - .../mach-iop32x/include/mach/entry-macro.S | 2 - arch/arm/mach-iop32x/include/mach/iop32x.h | 31 - arch/arm/mach-iop32x/include/mach/irqs.h | 33 - arch/arm/mach-iop32x/include/mach/time.h | 5 - .../arm/mach-iop32x/include/mach/uncompress.h | 18 +- .../asm/hardware => mach-iop32x}/iop3xx.h | 18 +- arch/arm/mach-iop32x/iq31244.c | 5 +- .../mach-iop32x/{include/mach => }/iq31244.h | 2 - arch/arm/mach-iop32x/iq80321.c | 5 +- .../mach-iop32x/{include/mach => }/iq80321.h | 2 - arch/arm/mach-iop32x/irq.c | 3 +- arch/arm/mach-iop32x/irqs.h | 42 + arch/arm/mach-iop32x/n2100.c | 5 +- .../mach-iop32x/{include/mach => }/n2100.h | 2 - arch/arm/{plat-iop => mach-iop32x}/pci.c | 4 +- arch/arm/{plat-iop => mach-iop32x}/pmu.c | 8 +- arch/arm/{plat-iop => mach-iop32x}/restart.c | 4 +- arch/arm/{plat-iop => mach-iop32x}/setup.c | 2 +- arch/arm/{plat-iop => mach-iop32x}/time.c | 7 +- arch/arm/mach-iop33x/Kconfig | 22 - arch/arm/mach-iop33x/Makefile | 9 - arch/arm/mach-iop33x/Makefile.boot | 4 - arch/arm/mach-iop33x/include/mach/adma.h | 6 - .../mach-iop33x/include/mach/entry-macro.S | 34 - arch/arm/mach-iop33x/include/mach/hardware.h | 44 - arch/arm/mach-iop33x/include/mach/iop33x.h | 37 - arch/arm/mach-iop33x/include/mach/iq80331.h | 17 - arch/arm/mach-iop33x/include/mach/iq80332.h | 17 - arch/arm/mach-iop33x/include/mach/irqs.h | 57 - arch/arm/mach-iop33x/include/mach/time.h | 5 - .../arm/mach-iop33x/include/mach/uncompress.h | 37 - arch/arm/mach-iop33x/iq80331.c | 148 --- arch/arm/mach-iop33x/iq80332.c | 148 --- arch/arm/mach-iop33x/irq.c | 115 -- arch/arm/mach-iop33x/uart.c | 100 -- arch/arm/mm/copypage-xscale.c | 6 +- arch/arm/plat-iop/Makefile | 28 - drivers/dma/Kconfig | 4 +- drivers/dma/iop-adma.c | 22 +- .../iop3xx-adma.h => drivers/dma/iop-adma.h | 7 +- drivers/gpio/Kconfig | 2 +- drivers/i2c/busses/Kconfig | 2 +- .../linux/platform_data/dma-iop32x.h | 4 + 78 files changed, 134 insertions(+), 5510 deletions(-) delete mode 100644 arch/arm/configs/iop13xx_defconfig delete mode 100644 arch/arm/configs/iop33x_defconfig delete mode 100644 arch/arm/mach-iop13xx/Kconfig delete mode 100644 arch/arm/mach-iop13xx/Makefile delete mode 100644 arch/arm/mach-iop13xx/Makefile.boot delete mode 100644 arch/arm/mach-iop13xx/include/mach/adma.h delete mode 100644 arch/arm/mach-iop13xx/include/mach/entry-macro.S delete mode 100644 arch/arm/mach-iop13xx/include/mach/hardware.h delete mode 100644 arch/arm/mach-iop13xx/include/mach/iop13xx.h delete mode 100644 arch/arm/mach-iop13xx/include/mach/iq81340.h delete mode 100644 arch/arm/mach-iop13xx/include/mach/irqs.h delete mode 100644 arch/arm/mach-iop13xx/include/mach/time.h delete mode 100644 arch/arm/mach-iop13xx/include/mach/uncompress.h delete mode 100644 arch/arm/mach-iop13xx/io.c delete mode 100644 arch/arm/mach-iop13xx/iq81340mc.c delete mode 100644 arch/arm/mach-iop13xx/iq81340sc.c delete mode 100644 arch/arm/mach-iop13xx/irq.c delete mode 100644 arch/arm/mach-iop13xx/msi.c delete mode 100644 arch/arm/mach-iop13xx/msi.h delete mode 100644 arch/arm/mach-iop13xx/pci.c delete mode 100644 arch/arm/mach-iop13xx/pci.h delete mode 100644 arch/arm/mach-iop13xx/setup.c delete mode 100644 arch/arm/mach-iop13xx/tpmi.c rename arch/arm/{plat-iop => mach-iop32x}/adma.c (75%) rename arch/arm/{plat-iop => mach-iop32x}/cp6.c (100%) rename arch/arm/mach-iop32x/{include/mach => }/glantank.h (78%) rename arch/arm/mach-iop32x/{include/mach => }/hardware.h (90%) rename arch/arm/{plat-iop => mach-iop32x}/i2c.c (81%) delete mode 100644 arch/arm/mach-iop32x/include/mach/adma.h delete mode 100644 arch/arm/mach-iop32x/include/mach/iop32x.h delete mode 100644 arch/arm/mach-iop32x/include/mach/time.h rename arch/arm/{include/asm/hardware => mach-iop32x}/iop3xx.h (96%) rename arch/arm/mach-iop32x/{include/mach => }/iq31244.h (89%) rename arch/arm/mach-iop32x/{include/mach => }/iq80321.h (89%) create mode 100644 arch/arm/mach-iop32x/irqs.h rename arch/arm/mach-iop32x/{include/mach => }/n2100.h (89%) rename arch/arm/{plat-iop => mach-iop32x}/pci.c (99%) rename arch/arm/{plat-iop => mach-iop32x}/pmu.c (79%) rename arch/arm/{plat-iop => mach-iop32x}/restart.c (82%) rename arch/arm/{plat-iop => mach-iop32x}/setup.c (95%) rename arch/arm/{plat-iop => mach-iop32x}/time.c (97%) delete mode 100644 arch/arm/mach-iop33x/Kconfig delete mode 100644 arch/arm/mach-iop33x/Makefile delete mode 100644 arch/arm/mach-iop33x/Makefile.boot delete mode 100644 arch/arm/mach-iop33x/include/mach/adma.h delete mode 100644 arch/arm/mach-iop33x/include/mach/entry-macro.S delete mode 100644 arch/arm/mach-iop33x/include/mach/hardware.h delete mode 100644 arch/arm/mach-iop33x/include/mach/iop33x.h delete mode 100644 arch/arm/mach-iop33x/include/mach/iq80331.h delete mode 100644 arch/arm/mach-iop33x/include/mach/iq80332.h delete mode 100644 arch/arm/mach-iop33x/include/mach/irqs.h delete mode 100644 arch/arm/mach-iop33x/include/mach/time.h delete mode 100644 arch/arm/mach-iop33x/include/mach/uncompress.h delete mode 100644 arch/arm/mach-iop33x/iq80331.c delete mode 100644 arch/arm/mach-iop33x/iq80332.c delete mode 100644 arch/arm/mach-iop33x/irq.c delete mode 100644 arch/arm/mach-iop33x/uart.c delete mode 100644 arch/arm/plat-iop/Makefile rename arch/arm/include/asm/hardware/iop3xx-adma.h => drivers/dma/iop-adma.h (99%) rename arch/arm/include/asm/hardware/iop_adma.h => include/linux/platform_data/dma-iop32x.h (98%)