From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Martin Michlmayr <tbm@cyrius.com>,
Peter Teichmann <lists@peter-teichmann.de>,
Arnd Bergmann <arnd@arndb.de>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
soc@kernel.org, Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Vinod Koul <vkoul@kernel.org>,
linux-i2c <linux-i2c@vger.kernel.org>,
dmaengine@vger.kernel.org,
Dan Williams <dan.j.williams@intel.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
Date: Fri, 16 Aug 2019 16:58:33 +0100 [thread overview]
Message-ID: <20190816155833.GL13294@shell.armlinux.org.uk> (raw)
In-Reply-To: <20190816154249.GA30291@darkstar.musicnaut.iki.fi>
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.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
next prev parent reply other threads:[~2019-08-16 15:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190809162956.488941-1-arnd@arndb.de>
2019-08-09 16:33 ` [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support Arnd Bergmann
2019-08-09 16:33 ` [PATCH 2/7] dma: iop-adma: include prefetch.h Arnd Bergmann
2019-08-13 4:33 ` Vinod Koul
2019-08-14 15:29 ` Arnd Bergmann
2019-08-09 16:33 ` [PATCH 3/7] dma: iop-adma: use correct printk format strings Arnd Bergmann
2019-08-13 4:33 ` Vinod Koul
2019-08-09 16:33 ` [PATCH 4/7] dma: iop-adma: allow building without platform headers Arnd Bergmann
2019-08-09 16:33 ` [PATCH 5/7] ARM: xscale: fix multi-cpu compilation Arnd Bergmann
2019-08-23 7:44 ` Linus Walleij
2019-08-09 16:33 ` [PATCH 6/7] ARM: iop32x: make mach/uncompress.h independent of mach/hardware.h Arnd Bergmann
2019-08-09 16:33 ` [PATCH 7/7] ARM: iop32x: merge everything into mach-iop32x/ Arnd Bergmann
2019-08-09 16:57 ` [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support Wolfram Sang
2019-08-09 18:34 ` Dan Williams
2019-08-09 18:36 ` Russell King - ARM Linux admin
2019-08-09 19:43 ` Dan Williams
2019-08-12 9:44 ` Martin Michlmayr
2019-08-14 8:36 ` Linus Walleij
2019-08-14 10:48 ` Arnd Bergmann
2019-08-16 15:42 ` Aaro Koskinen
2019-08-16 15:58 ` Russell King - ARM Linux admin [this message]
2019-08-16 16:15 ` Aaro Koskinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190816155833.GL13294@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=aaro.koskinen@iki.fi \
--cc=arnd@arndb.de \
--cc=bgolaszewski@baylibre.com \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lists@peter-teichmann.de \
--cc=soc@kernel.org \
--cc=tbm@cyrius.com \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).