public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
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

  parent reply	other threads:[~2018-02-22 23:48 UTC|newest]

Thread overview: 59+ 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 16:02 ` Christoph Hellwig
2018-02-22 16:19   ` Arnd Bergmann
2018-02-22 17:14   ` Max Filippov
2018-02-22 18:04     ` Christoph Hellwig
2018-02-23 11:37       ` Arnd Bergmann
2018-02-28  8:59         ` Florian Weimer
2018-02-28  8:59           ` Florian Weimer
2018-02-22 16:07 ` Lennox Wu
2018-02-22 16:28 ` James Hogan
2018-02-22 16:34   ` Arnd Bergmann
2018-02-22 19:17 ` Richard Kuo
2018-02-22 22:43   ` Arnd Bergmann
2018-02-23 17:15     ` Richard Kuo
2018-02-28  2:06     ` Richard Kuo
2018-02-28  2:06       ` Richard Kuo
2018-02-28  8:37       ` Arnd Bergmann
2018-02-28  8:37         ` Arnd Bergmann
2018-03-03  1:43         ` Richard Kuo
2018-03-03  1:43           ` Richard Kuo
2018-02-22 23:48 ` Guenter Roeck [this message]
2018-02-23 10:32   ` Arnd Bergmann
2018-02-23 12:09     ` Andy Shevchenko
2018-02-23 12:20       ` Arnd Bergmann
2018-02-23 14:32     ` Guenter Roeck
2018-02-23 15:43     ` Alan Cox
2018-02-23 17:10       ` Guenter Roeck
2018-02-23 18:19         ` Al Viro
2018-02-23 19:32           ` James Bottomley
2018-02-23 21:34             ` Adam Borowski
2018-02-24  4:04               ` Guenter Roeck
2018-02-24 21:55             ` Guenter Roeck
2018-02-25 19:39           ` [OpenRISC] " Richard Henderson
2018-02-23 23:49         ` Greg Ungerer
2018-02-25 20:28         ` Alan Cox
2018-02-25 22:50           ` Pavel Machek
2018-02-25 22:50             ` Pavel Machek
2018-02-24  0:15 ` Florian Fainelli
2018-02-26  8:26   ` Arnd Bergmann
2018-02-26  8:26     ` Arnd Bergmann
2018-02-26 22:11     ` Eric W. Biederman
2018-02-26 22:11       ` Eric W. Biederman
     [not found]     ` <5ef16c51-7cc5-9111-7e54-edfe77f39f4b@metafoo.de>
2018-03-05 10:57       ` Wu, Aaron
2018-03-06  9:38         ` Arnd Bergmann
2018-03-06 10:35           ` Wu, Aaron
2018-03-06 10:38             ` Arnd Bergmann
2018-02-25 15:43 ` [OpenRISC] " 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   ` Xuetao Guan
  -- strict thread matches above, loose matches on Subject: below --
2018-03-09 14:18 Guan Xuetao
2018-03-09 14:18 ` Guan Xuetao
2018-03-09 14:33 ` Arnd Bergmann
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox