From: Guenter Roeck <linux@roeck-us.net>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch <linux-arch@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Richard Kuo <rkuo@codeaurora.org>,
linux-hexagon@vger.kernel.org, Chen Liqin <liqin.linux@gmail.com>,
Lennox Wu <lennox.wu@gmail.com>,
Guan Xuetao <gxt@mprc.pku.edu.cn>,
Al Viro <viro@zeniv.linux.org.uk>,
James Hogan <jhogan@kernel.org>,
linux-metag@vger.kernel.org, Jonas Bonn <jonas@southpole.se>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
Stafford Horne <shorne@gmail.com>,
openrisc@lists.librecores.org,
David Howells <dhowells@redhat.com>
Subject: Re: Removing architectures without upstream gcc support
Date: Thu, 22 Feb 2018 15:48:33 -0800 [thread overview]
Message-ID: <20180222234833.GA3047@roeck-us.net> (raw)
In-Reply-To: <CAK8P3a2-6YwRR3j7J78fVHSvDpq8Kf4wRj6d9mnGgAxgkYypxg@mail.gmail.com>
On Thu, Feb 22, 2018 at 04:45:06PM +0100, Arnd Bergmann wrote:
> While building the cross-toolchains, I noticed that overall, we can build almost
> all linux target architectures with upstream binutils and gcc these days,
> however there are still some exceptions, and I'd like to find out if anyone
> has objections to removing the ones that do not have upstream support.
> This are the four architectures I found:
>
> * score (s+core, sunplus core) was a proprietary RISC architecture
> made by sunplus. It is unclear if they still ship any products based on
> this architecture, all they list is either ARM Cortex-A9 or an unspecified
> RISC core that could be any of arm, mips, nds32, arc, xtensa or
> something completely different. The two maintainers have both left the
> company many years ago and have not contributed any patches in
> at least five years. There was an upstream gcc port, which was marked
> 'obsolete' in 2013 and got removed in gcc-5.0.
> I conclude that this is dead in Linux and can be removed
>
> * unicore32 was a research project at Peking University with a SoC
> based on the Intel PXA design. No gcc source code has ever been
> published, the only toolchain available is a set of binaries that include
> a gcc-4.4 compiler. The project page at
> http://mprc.pku.edu.cn/~guanxuetao/linux/ has a TODO list that has
> not been modified since 2011. The maintainer still Acks patches
> and has last sent a pull request in 2014 and last sent a patch of
> his own in 2012 when the project appears to have stalled.
> I would suggest removing this one.
>
The above two would be primary removal targets for me; they are all
but impossible to support given the toolchain limitations. Meta
would have been another one, but James is already taking care of it.
Guenter
> * Hexagon is Qualcomm's DSP architecture. It is being actively used
> in all Snapdragon ARM SoCs, but the kernel code appears to be
> the result of a failed research project to make a standalone Hexagon
> SoC without an ARM core. There is some information about the
> project at https://wiki.codeaurora.org/xwiki/bin/Hexagon/ and
> https://unix.stackexchange.com/questions/246243/what-is-was-the-qualcomm-hexagon-comet-board
> There is a port to gcc-4.5 on the project page, which is evidently
> abandoned, but there is an active upstream LLVM port that is
> apparently used to build non-Linux programs.
> I would consider this one a candidate for removal as well, given that
> there were never any machines outside of Qualcomm that used this,
> and they are no longer interested themselves.
>
> * Meta was ImgTec's own architecture and they upstreamed the kernel
> port just before they acquired MIPS. Apparently Meta was abandoned
> shortly afterwards and disappeared from imgtec's website in 2014.
> The maintainer is still fixing bugs in the port, but I could not find
> any toolchain more recent than
> https://github.com/img-meta/metag-buildroot/tree/metag-core/toolchain/gcc/4.2.4
> Not sure about this one, I'd be interested in more background
> from James Hogan, who probably has an opinion and might have
> newer toolchain sources.
>
> * OpenRISC is a RISC architecture with a free license and an
> active community. It seems to have lost a bit of steam after RISC-V
> is rapidly taking over that niche, but there are chips out there and
> the design isn't going away. Listing it here for completeness only
> because there is no upstream gcc port yet, but this will hopefully
> change in the future based on
> https://lists.librecores.org/pipermail/openrisc/2018-January/000958.html
> and I had no problems locating the gcc-7.x tree for building my
> toolchains. The port is actively being maintained.
>
> There are also a couple of architectures that are more or less
> unmaintained but do have working gcc support: FR-V and M32R
> have been orphaned for a while and are not getting updated
> MN10300 is still maintained officially by David Howells but doesn't
> seem any more active than the other two, the last real updates were
> in 2013.
>
> Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] Removing architectures without upstream gcc support
Date: Thu, 22 Feb 2018 15:48:33 -0800 [thread overview]
Message-ID: <20180222234833.GA3047@roeck-us.net> (raw)
In-Reply-To: <CAK8P3a2-6YwRR3j7J78fVHSvDpq8Kf4wRj6d9mnGgAxgkYypxg@mail.gmail.com>
On Thu, Feb 22, 2018 at 04:45:06PM +0100, Arnd Bergmann wrote:
> While building the cross-toolchains, I noticed that overall, we can build almost
> all linux target architectures with upstream binutils and gcc these days,
> however there are still some exceptions, and I'd like to find out if anyone
> has objections to removing the ones that do not have upstream support.
> This are the four architectures I found:
>
> * score (s+core, sunplus core) was a proprietary RISC architecture
> made by sunplus. It is unclear if they still ship any products based on
> this architecture, all they list is either ARM Cortex-A9 or an unspecified
> RISC core that could be any of arm, mips, nds32, arc, xtensa or
> something completely different. The two maintainers have both left the
> company many years ago and have not contributed any patches in
> at least five years. There was an upstream gcc port, which was marked
> 'obsolete' in 2013 and got removed in gcc-5.0.
> I conclude that this is dead in Linux and can be removed
>
> * unicore32 was a research project at Peking University with a SoC
> based on the Intel PXA design. No gcc source code has ever been
> published, the only toolchain available is a set of binaries that include
> a gcc-4.4 compiler. The project page at
> http://mprc.pku.edu.cn/~guanxuetao/linux/ has a TODO list that has
> not been modified since 2011. The maintainer still Acks patches
> and has last sent a pull request in 2014 and last sent a patch of
> his own in 2012 when the project appears to have stalled.
> I would suggest removing this one.
>
The above two would be primary removal targets for me; they are all
but impossible to support given the toolchain limitations. Meta
would have been another one, but James is already taking care of it.
Guenter
> * Hexagon is Qualcomm's DSP architecture. It is being actively used
> in all Snapdragon ARM SoCs, but the kernel code appears to be
> the result of a failed research project to make a standalone Hexagon
> SoC without an ARM core. There is some information about the
> project at https://wiki.codeaurora.org/xwiki/bin/Hexagon/ and
> https://unix.stackexchange.com/questions/246243/what-is-was-the-qualcomm-hexagon-comet-board
> There is a port to gcc-4.5 on the project page, which is evidently
> abandoned, but there is an active upstream LLVM port that is
> apparently used to build non-Linux programs.
> I would consider this one a candidate for removal as well, given that
> there were never any machines outside of Qualcomm that used this,
> and they are no longer interested themselves.
>
> * Meta was ImgTec's own architecture and they upstreamed the kernel
> port just before they acquired MIPS. Apparently Meta was abandoned
> shortly afterwards and disappeared from imgtec's website in 2014.
> The maintainer is still fixing bugs in the port, but I could not find
> any toolchain more recent than
> https://github.com/img-meta/metag-buildroot/tree/metag-core/toolchain/gcc/4.2.4
> Not sure about this one, I'd be interested in more background
> from James Hogan, who probably has an opinion and might have
> newer toolchain sources.
>
> * OpenRISC is a RISC architecture with a free license and an
> active community. It seems to have lost a bit of steam after RISC-V
> is rapidly taking over that niche, but there are chips out there and
> the design isn't going away. Listing it here for completeness only
> because there is no upstream gcc port yet, but this will hopefully
> change in the future based on
> https://lists.librecores.org/pipermail/openrisc/2018-January/000958.html
> and I had no problems locating the gcc-7.x tree for building my
> toolchains. The port is actively being maintained.
>
> There are also a couple of architectures that are more or less
> unmaintained but do have working gcc support: FR-V and M32R
> have been orphaned for a while and are not getting updated
> MN10300 is still maintained officially by David Howells but doesn't
> seem any more active than the other two, the last real updates were
> in 2013.
>
> Arnd
next prev parent reply other threads:[~2018-02-22 23:48 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-22 15:45 Removing architectures without upstream gcc support Arnd Bergmann
2018-02-22 15:45 ` [OpenRISC] " Arnd Bergmann
2018-02-22 15:52 ` Lennox Wu
2018-02-22 16:02 ` Christoph Hellwig
2018-02-22 16:02 ` [OpenRISC] " Christoph Hellwig
2018-02-22 16:19 ` Arnd Bergmann
2018-02-22 16:19 ` [OpenRISC] " Arnd Bergmann
2018-02-22 17:14 ` Max Filippov
2018-02-22 17:14 ` [OpenRISC] " Max Filippov
2018-02-22 18:04 ` Christoph Hellwig
2018-02-22 18:04 ` [OpenRISC] " Christoph Hellwig
2018-02-23 11:37 ` Arnd Bergmann
2018-02-23 11:37 ` [OpenRISC] " Arnd Bergmann
2018-02-28 8:59 ` Florian Weimer
2018-02-28 8:59 ` [OpenRISC] " Florian Weimer
2018-02-22 16:07 ` Lennox Wu
2018-02-22 16:07 ` [OpenRISC] " Lennox Wu
2018-02-22 16:28 ` James Hogan
2018-02-22 16:28 ` [OpenRISC] " James Hogan
2018-02-22 16:34 ` Arnd Bergmann
2018-02-22 16:34 ` [OpenRISC] " Arnd Bergmann
2018-02-22 19:17 ` Richard Kuo
2018-02-22 19:17 ` [OpenRISC] " Richard Kuo
2018-02-22 22:43 ` Arnd Bergmann
2018-02-22 22:43 ` [OpenRISC] " Arnd Bergmann
2018-02-23 17:15 ` Richard Kuo
2018-02-23 17:15 ` [OpenRISC] " Richard Kuo
2018-02-28 2:06 ` Richard Kuo
2018-02-28 2:06 ` [OpenRISC] " Richard Kuo
2018-02-28 8:37 ` Arnd Bergmann
2018-02-28 8:37 ` [OpenRISC] " Arnd Bergmann
2018-03-03 1:43 ` Richard Kuo
2018-03-03 1:43 ` [OpenRISC] " Richard Kuo
2018-02-22 23:48 ` Guenter Roeck [this message]
2018-02-22 23:48 ` Guenter Roeck
2018-02-23 10:32 ` Arnd Bergmann
2018-02-23 10:32 ` [OpenRISC] " Arnd Bergmann
2018-02-23 12:09 ` Andy Shevchenko
2018-02-23 12:09 ` [OpenRISC] " Andy Shevchenko
2018-02-23 12:20 ` Arnd Bergmann
2018-02-23 12:20 ` [OpenRISC] " Arnd Bergmann
2018-02-23 14:32 ` Guenter Roeck
2018-02-23 14:32 ` [OpenRISC] " Guenter Roeck
2018-02-23 15:43 ` Alan Cox
2018-02-23 15:43 ` [OpenRISC] " Alan Cox
2018-02-23 17:10 ` Guenter Roeck
2018-02-23 17:10 ` [OpenRISC] " Guenter Roeck
2018-02-23 18:19 ` Al Viro
2018-02-23 18:19 ` [OpenRISC] " Al Viro
2018-02-23 19:32 ` James Bottomley
2018-02-23 19:32 ` [OpenRISC] " James Bottomley
2018-02-23 21:34 ` Adam Borowski
2018-02-23 21:34 ` [OpenRISC] " Adam Borowski
2018-02-24 4:04 ` Guenter Roeck
2018-02-24 4:04 ` [OpenRISC] " Guenter Roeck
2018-02-24 21:55 ` Guenter Roeck
2018-02-24 21:55 ` [OpenRISC] " Guenter Roeck
2018-02-25 19:39 ` Richard Henderson
2018-02-25 19:39 ` Richard Henderson
2018-02-23 23:49 ` Greg Ungerer
2018-02-23 23:49 ` [OpenRISC] " Greg Ungerer
2018-02-25 20:28 ` Alan Cox
2018-02-25 20:28 ` [OpenRISC] " Alan Cox
2018-02-25 22:50 ` Pavel Machek
2018-02-25 22:50 ` [OpenRISC] " Pavel Machek
2018-02-24 0:15 ` Florian Fainelli
2018-02-24 0:15 ` [OpenRISC] " Florian Fainelli
2018-02-26 8:26 ` Arnd Bergmann
2018-02-26 8:26 ` [OpenRISC] " Arnd Bergmann
2018-02-26 22:11 ` Eric W. Biederman
2018-02-26 22:11 ` Eric W. Biederman
2018-02-26 22:11 ` [OpenRISC] " Eric W. Biederman
[not found] ` <5ef16c51-7cc5-9111-7e54-edfe77f39f4b@metafoo.de>
2018-03-05 10:57 ` Wu, Aaron
2018-03-05 10:57 ` [OpenRISC] " Wu, Aaron
2018-03-06 9:38 ` Arnd Bergmann
2018-03-06 9:38 ` [OpenRISC] " Arnd Bergmann
2018-03-06 10:35 ` Wu, Aaron
2018-03-06 10:35 ` [OpenRISC] " Wu, Aaron
2018-03-06 10:38 ` Arnd Bergmann
2018-03-06 10:38 ` [OpenRISC] " Arnd Bergmann
2018-02-25 15:43 ` Philipp Wagner
2018-02-25 15:43 ` Philipp Wagner
2018-02-26 8:00 ` Arnd Bergmann
2018-02-26 8:00 ` Arnd Bergmann
2018-02-26 12:10 ` Philipp Wagner
2018-02-26 12:10 ` Philipp Wagner
2018-02-26 15:24 ` whitequark
2018-02-26 15:24 ` whitequark
2018-03-09 14:00 ` Xuetao Guan
2018-03-09 14:00 ` [OpenRISC] " Xuetao Guan
-- strict thread matches above, loose matches on Subject: below --
2018-03-09 14:18 Guan Xuetao
2018-03-09 14:33 ` Arnd Bergmann
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=20180222234833.GA3047@roeck-us.net \
--to=linux@roeck-us.net \
--cc=arnd@arndb.de \
--cc=dhowells@redhat.com \
--cc=gxt@mprc.pku.edu.cn \
--cc=jhogan@kernel.org \
--cc=jonas@southpole.se \
--cc=lennox.wu@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-metag@vger.kernel.org \
--cc=liqin.linux@gmail.com \
--cc=openrisc@lists.librecores.org \
--cc=rkuo@codeaurora.org \
--cc=shorne@gmail.com \
--cc=stefan.kristiansson@saunalahti.fi \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.