From: Richard Kuo <rkuo@codeaurora.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch <linux-arch@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.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>,
Guenter Roeck <linux@roeck-us.net>,
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: Fri, 23 Feb 2018 11:15:43 -0600 [thread overview]
Message-ID: <20180223171543.GA3780@codeaurora.org> (raw)
In-Reply-To: <CAK8P3a3r=3wDtqV5feLUT-hOkE+9yWOLjLVm+nejqdaN7MtMFw@mail.gmail.com>
On Thu, Feb 22, 2018 at 11:43:10PM +0100, Arnd Bergmann wrote:
> On Thu, Feb 22, 2018 at 8:17 PM, Richard Kuo <rkuo@codeaurora.org> wrote:
> > On Thu, Feb 22, 2018 at 04:45:06PM +0100, Arnd Bergmann wrote:
> >> * 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.
> >
> > It's difficult for me to speak to the decisions as I can understand
> > your point of view, but maybe I can speak to some of the status.
> >
> > We still use the port internally for kicking the tools around and other
> > research projects. As you noticed we're not doing gcc anymore; we're
> > using LLVM for both kernel and userspace. Yes there have been some
> > caveats but it does work within confines.
> >
> > Time is unfortunately just limited for me to upstream some of my kernel
> > fixes and cleanups, and there are some things that just haven't shown
> > up externally yet.
> >
> > However, as James Hogan mentioned, having it in the tree really has been
> > useful because it gets included in the various upstream changes and
> > fixes, which we appreciate.
> >
> > So hopefully this will help inform the decision a little better.
> >
> > If you have any other questions please let me know.
>
> Thanks for the clarification! Since you are the maintainer and you
> still consider the port useful, I don't see how anyone else would be
> in a position to demand it to be removed, so we should keep it
> around until you want it gone.
>
> I still have a few questions:
>
> - Any idea how we would find out of the status ever changes? E.g. if
> you decide at some point that you don't find the latest Linux useful
> any more for your internal work, would you send a patch for removal?
Yes, we can definitely notify everyone if this happens.
> - How do I build an llvm based toolchain for Hexagon? Do I need patches
> on top of the llvm-6 release branch? Where can I find the corresponding
> binutils-2.30 sources?
The Hexagon LLVM tools available from Qualcomm should have an ABI switch
that's supposed to work for this:
-target hexagon-unknown-linux
Admittedly I haven't tried that one. I'm unsure about the full upstream
status; I'll check on that, but I think the sketchiest component out of
that bunch is currently going to be the linker.
Let me do some checking on all this the next couple of days and get
a better answer.
Thanks,
Richard Kuo
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
WARNING: multiple messages have this Message-ID (diff)
From: Richard Kuo <rkuo@codeaurora.org>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] Removing architectures without upstream gcc support
Date: Fri, 23 Feb 2018 11:15:43 -0600 [thread overview]
Message-ID: <20180223171543.GA3780@codeaurora.org> (raw)
In-Reply-To: <CAK8P3a3r=3wDtqV5feLUT-hOkE+9yWOLjLVm+nejqdaN7MtMFw@mail.gmail.com>
On Thu, Feb 22, 2018 at 11:43:10PM +0100, Arnd Bergmann wrote:
> On Thu, Feb 22, 2018 at 8:17 PM, Richard Kuo <rkuo@codeaurora.org> wrote:
> > On Thu, Feb 22, 2018 at 04:45:06PM +0100, Arnd Bergmann wrote:
> >> * 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.
> >
> > It's difficult for me to speak to the decisions as I can understand
> > your point of view, but maybe I can speak to some of the status.
> >
> > We still use the port internally for kicking the tools around and other
> > research projects. As you noticed we're not doing gcc anymore; we're
> > using LLVM for both kernel and userspace. Yes there have been some
> > caveats but it does work within confines.
> >
> > Time is unfortunately just limited for me to upstream some of my kernel
> > fixes and cleanups, and there are some things that just haven't shown
> > up externally yet.
> >
> > However, as James Hogan mentioned, having it in the tree really has been
> > useful because it gets included in the various upstream changes and
> > fixes, which we appreciate.
> >
> > So hopefully this will help inform the decision a little better.
> >
> > If you have any other questions please let me know.
>
> Thanks for the clarification! Since you are the maintainer and you
> still consider the port useful, I don't see how anyone else would be
> in a position to demand it to be removed, so we should keep it
> around until you want it gone.
>
> I still have a few questions:
>
> - Any idea how we would find out of the status ever changes? E.g. if
> you decide at some point that you don't find the latest Linux useful
> any more for your internal work, would you send a patch for removal?
Yes, we can definitely notify everyone if this happens.
> - How do I build an llvm based toolchain for Hexagon? Do I need patches
> on top of the llvm-6 release branch? Where can I find the corresponding
> binutils-2.30 sources?
The Hexagon LLVM tools available from Qualcomm should have an ABI switch
that's supposed to work for this:
-target hexagon-unknown-linux
Admittedly I haven't tried that one. I'm unsure about the full upstream
status; I'll check on that, but I think the sketchiest component out of
that bunch is currently going to be the linker.
Let me do some checking on all this the next couple of days and get
a better answer.
Thanks,
Richard Kuo
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2018-02-23 17:15 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 [this message]
2018-02-23 17:15 ` 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
2018-02-22 23:48 ` [OpenRISC] " 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=20180223171543.GA3780@codeaurora.org \
--to=rkuo@codeaurora.org \
--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=linux@roeck-us.net \
--cc=liqin.linux@gmail.com \
--cc=openrisc@lists.librecores.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.