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.
* 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
On Thu, Feb 22, 2018 at 04:45:06PM +0100, Arnd Bergmann wrote:
> 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.
I'd love to see dead architecture ports dropped if they really are
more or less abandoned. In addition to your missing gcc port ones
above (minus openrisc) it seems like frv and m32r certainly qualify,
and xtensa seems to be going that way with the glibc port being dropped
now.
Hi all,
We agree to remove the Score arch.
I have discussed the status with Sunplus, and they plan to replace the
arch with ARM.
I will make a request to remove Linux kernel, too.
Best,
Lennox
2018-02-22 23:45 GMT+08:00 Arnd Bergmann <[email protected]>:
> 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.
>
> * 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
On Thu, Feb 22, 2018 at 5:02 PM, Christoph Hellwig <[email protected]> wrote:
> On Thu, Feb 22, 2018 at 04:45:06PM +0100, Arnd Bergmann wrote:
>> 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.
>
> I'd love to see dead architecture ports dropped if they really are
> more or less abandoned. In addition to your missing gcc port ones
> above (minus openrisc) it seems like frv and m32r certainly qualify,
> and xtensa seems to be going that way with the glibc port being dropped
> now.
Regarding xtensa, I looked at that one while I wrote my list and it seems
quite a bit more active than the others. Cris and xtensa are two architectures
that don't see much maintenance over long periods of time but occasionally
get a proper update. For xtensa this just happened, see [1]. Unlike cris,
xtensa is also commercially still very successful, just less so in the
Linux+glibc space.
Arnd
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d0bd31dc5c0b46b9c778112900cf8f910ac26e1b
Hi Arnd,
On Thu, Feb 22, 2018 at 04:45:06PM +0100, Arnd Bergmann wrote:
> * 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.
Interesting timing! Have you seen this (which I'll send for 4.17, and
leave 4.16 broken)?
https://marc.info/?l=linux-kernel&m=151925667323732&w=2
The Meta port is essentially unused and for a while I have only looked
at it when something went wrong. PURE's Linux based digital radios I
believe were never updated to 3.10. The fact that the GCC port wasn't
upstreamed before the MIPS acquisition meant it was always a ticking
time bomb (though binutils was upstreamed).
Sad really, given that at least 9 years of effort went into the port
before permission was finally given to upstream it, and within a week or
so of the first patchset the intention to acquire MIPS was announced.
FWIW, my experience was that upstreaming the port caught a whole lot of
issues (Al Viro's review of signal handling alone was tremendously
valuable), and drastically reduced the effort required to forward port
to each new kernel version. Updating an out of tree arch tends to result
in a lot of runtime failures that require digging, which reduced
drastically once the port was upstreamed.
Cheers
James
On Thu, Feb 22, 2018 at 5:28 PM, James Hogan <[email protected]> wrote:
> Hi Arnd,
>
> On Thu, Feb 22, 2018 at 04:45:06PM +0100, Arnd Bergmann wrote:
>> * 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.
>
> Interesting timing! Have you seen this (which I'll send for 4.17, and
> leave 4.16 broken)?
>
> https://marc.info/?l=linux-kernel&m=151925667323732&w=2
No, I missed that. Could have saved me some of the research I did
when coming up with the list ;-)
> The Meta port is essentially unused and for a while I have only looked
> at it when something went wrong. PURE's Linux based digital radios I
> believe were never updated to 3.10. The fact that the GCC port wasn't
> upstreamed before the MIPS acquisition meant it was always a ticking
> time bomb (though binutils was upstreamed).
>
> Sad really, given that at least 9 years of effort went into the port
> before permission was finally given to upstream it, and within a week or
> so of the first patchset the intention to acquire MIPS was announced.
Indeed.
Arnd
On Thu, Feb 22, 2018 at 8:02 AM, Christoph Hellwig <[email protected]> wrote:
> I'd love to see dead architecture ports dropped if they really are
> more or less abandoned. In addition to your missing gcc port ones
> above (minus openrisc) it seems like frv and m32r certainly qualify,
> and xtensa seems to be going that way with the glibc port being dropped
> now.
It's not that it's been dropped, there have never been an official glibc
port for xtensa, but we're working to get one.
--
Thanks.
-- Max
On Thu, Feb 22, 2018 at 09:14:11AM -0800, Max Filippov wrote:
> On Thu, Feb 22, 2018 at 8:02 AM, Christoph Hellwig <[email protected]> wrote:
> > I'd love to see dead architecture ports dropped if they really are
> > more or less abandoned. In addition to your missing gcc port ones
> > above (minus openrisc) it seems like frv and m32r certainly qualify,
> > and xtensa seems to be going that way with the glibc port being dropped
> > now.
>
> It's not that it's been dropped, there have never been an official glibc
> port for xtensa, but we're working to get one.
Ah sorry - I meant to say tile not xtensa when writing this.
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,
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
On Thu, Feb 22, 2018 at 8:17 PM, Richard Kuo <[email protected]> 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?
- 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?
Arnd
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
On Fri, Feb 23, 2018 at 12:48 AM, Guenter Roeck <[email protected]> wrote:
> 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.
Ok. Have you had any success building arch/hexagon with clang?
Regarding the older architectures I mentioned (m32r, frv, mn10300),
the situation is a bit different as they don't have the problems with
build testing but they do have problems with using less of the
standard interfaces (syscall, timer, gpio, rtc, ...), so they do add
more to the maintenance burden without the nostalgia value of
some of the even older architectures (parisc, alpha, m68k, ia64)
that people maintain mainly for fun.
Arnd
On Thu, Feb 22, 2018 at 7:04 PM, Christoph Hellwig <[email protected]> wrote:
> On Thu, Feb 22, 2018 at 09:14:11AM -0800, Max Filippov wrote:
>> On Thu, Feb 22, 2018 at 8:02 AM, Christoph Hellwig <[email protected]> wrote:
>> > I'd love to see dead architecture ports dropped if they really are
>> > more or less abandoned. In addition to your missing gcc port ones
>> > above (minus openrisc) it seems like frv and m32r certainly qualify,
>> > and xtensa seems to be going that way with the glibc port being dropped
>> > now.
>>
>> It's not that it's been dropped, there have never been an official glibc
>> port for xtensa, but we're working to get one.
>
> Ah sorry - I meant to say tile not xtensa when writing this.
That makes more sense, yes. I'm still unsure about this one though. Chris in
fact made the suggestion to remove the architecture from both glibc and kernel
as with his departure from Mellanox there is nobody left from to maintain it.
I suggested keeping it as 'Orphaned' for the time being, given that the port
is still in a good shape, much better than many other ports.
The known customers that sold TileGX based appliances (Cisco, Brocade,
Checkpoint, Mikrotik, ...) tend to have long support cycles, and there have
been attempts at getting Debian, OpenWRT and Centos distro support
at least a few years ago.
According to one comment, at least Cisco doesn't use the mainline kernels [1],
and it's likely similar for the others.
The other architecture that was recently marked 'obsolete' is Blackfin,
if we remove Tile, then that one can probably get removed as well.
Arnd
[1] http://sourceware-org.1504.n7.nabble.com/RFC-remove-the-quot-tile-quot-architecture-from-glibc-td486836i20.html#a491434
On Fri, Feb 23, 2018 at 12:32 PM, Arnd Bergmann <[email protected]> wrote:
> some of the even older architectures (parisc, alpha, m68k, ia64)
> that people maintain mainly for fun.
alpha is not only for fun but for seeing how out of order can screw up
the "working" code.
ia64 as far as I *heard* from some news will be in support (I mean by
vendors) for few more years. Not a fun, just business.
--
With Best Regards,
Andy Shevchenko
On Fri, Feb 23, 2018 at 1:09 PM, Andy Shevchenko
<[email protected]> wrote:
> On Fri, Feb 23, 2018 at 12:32 PM, Arnd Bergmann <[email protected]> wrote:
>
> ia64 as far as I *heard* from some news will be in support (I mean by
> vendors) for few more years. Not a fun, just business.
My impression was that the business side is only on enterprise distros
(SLES11 is still supported, RHEL5 is on 'extended support' only), but not
with mainline kernels. Anyway, it doesn't matter as nobody is suggestion
to remove it any time soon.
Arnd
On 02/23/2018 02:32 AM, Arnd Bergmann wrote:
> On Fri, Feb 23, 2018 at 12:48 AM, Guenter Roeck <[email protected]> wrote:
>> 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.
>
> Ok. Have you had any success building arch/hexagon with clang?
>
I have not tried. It is a pain having to use different toolchains for different
kernel versions, and I only do it if I absolutely have to. I use "hexagon-linux-gcc
(Sourcery CodeBench Lite 2012.03-66) 4.6.1".
Guenter
> Regarding the older architectures I mentioned (m32r, frv, mn10300),
> the situation is a bit different as they don't have the problems with
> build testing but they do have problems with using less of the
> standard interfaces (syscall, timer, gpio, rtc, ...), so they do add
> more to the maintenance burden without the nostalgia value of
> some of the even older architectures (parisc, alpha, m68k, ia64)
> that people maintain mainly for fun.
IMHO the magic word is 'maintain'. If someone is actively maintaining it
then I don't think we should care too much, if not then while the code
may be buildable on current systems does anyone honestly think it works
properly if used in anger ?
Alan
On Fri, Feb 23, 2018 at 03:43:16PM +0000, Alan Cox wrote:
> > Regarding the older architectures I mentioned (m32r, frv, mn10300),
> > the situation is a bit different as they don't have the problems with
> > build testing but they do have problems with using less of the
> > standard interfaces (syscall, timer, gpio, rtc, ...), so they do add
> > more to the maintenance burden without the nostalgia value of
> > some of the even older architectures (parisc, alpha, m68k, ia64)
> > that people maintain mainly for fun.
>
> IMHO the magic word is 'maintain'. If someone is actively maintaining it
> then I don't think we should care too much, if not then while the code
> may be buildable on current systems does anyone honestly think it works
> properly if used in anger ?
>
FWIW, alpha and m68k are known boot with qemu (even though m68k
generates a warning traceback with the mainline kernel).
Guenter
On Thu, Feb 22, 2018 at 11:43:10PM +0100, Arnd Bergmann wrote:
> On Thu, Feb 22, 2018 at 8:17 PM, Richard Kuo <[email protected]> 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
On Fri, Feb 23, 2018 at 09:10:19AM -0800, Guenter Roeck wrote:
> FWIW, alpha and m68k are known boot with qemu (even though m68k
> generates a warning traceback with the mainline kernel).
alpha works with qemu (I considered putting together a debian
autobuilder on that, got mired in the scripts; builds AFAICS
happen the same way as on the actual hardware, and considerably
faster than any of the alpha boxen I've got here). For m68k,
IIRC, qemu is mostly for coldfire and friends with aranym
working for m68k/MMU testing.
IIRC, parisc/qemu stuff had been announced a while ago; I hadn't
tried that yet (got an old parisc box, so 32bit testing can be
done on that). Itanic... ski(1) is, IME, not usable for kernel
testing and AFAIK no usable ia64/qemu exists. That's another
one that has to be tested on actual hardware.
On Fri, 2018-02-23 at 18:19 +0000, Al Viro wrote:
[...]
> IIRC, parisc/qemu stuff had been announced a while ago;
I have, but it didn't work sufficiently for me to either boot a kernel
using system emulation or start an architecture container using user
emulation. I'll try again now that qemu has gone through several
revisions.
> I hadn't tried that yet (got an old parisc box, so 32bit testing can
> be done on that).
The mailing list ([email protected]) does regular build
testing on a variety of 32 and 64 bit hardware.
James
On Fri, Feb 23, 2018 at 02:32:08PM -0500, James Bottomley wrote:
> On Fri, 2018-02-23 at 18:19 +0000, Al Viro wrote:
> [...]
> > IIRC, parisc/qemu stuff had been announced a while ago;
>
> I have, but it didn't work sufficiently for me to either boot a kernel
> using system emulation or start an architecture container using user
> emulation. I'll try again now that qemu has gone through several
> revisions.
Doesn't seem to work. Debian package (1:2.11+dfsg-1) ships hppa support but
it doesn't even install binfmt; otherwise, -user is functional enough for a
minimal executable (so arch-test reports it as working[1]), but not for
anything libc:
[/srv/chroots/hppa]# chroot . /usr/bin/qemu-hppa-static /bin/true
qemu-hppa-static: /build/qemu-v8TF72/qemu-2.11+dfsg/target/hppa/translate.c:422: nullify_end: Assertion `status != DISAS_NORETURN && status != DISAS_IAQ_N_UPDATED' failed.
Segmentation fault
This looks bad enough that I didn't even look at qemu-system.
ᛗᛖᛟᚹ!
[1]. On archs without changed baseline, the test is just
write(1,"ok\n",3);_exit(0); unless there's a known issue to look for
such as swpb emulation being nop, etc.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄⠀⠀⠀⠀
On 24/02/18 03:10, Guenter Roeck wrote:
> On Fri, Feb 23, 2018 at 03:43:16PM +0000, Alan Cox wrote:
>>> Regarding the older architectures I mentioned (m32r, frv, mn10300),
>>> the situation is a bit different as they don't have the problems with
>>> build testing but they do have problems with using less of the
>>> standard interfaces (syscall, timer, gpio, rtc, ...), so they do add
>>> more to the maintenance burden without the nostalgia value of
>>> some of the even older architectures (parisc, alpha, m68k, ia64)
>>> that people maintain mainly for fun.
>>
>> IMHO the magic word is 'maintain'. If someone is actively maintaining it
>> then I don't think we should care too much, if not then while the code
>> may be buildable on current systems does anyone honestly think it works
>> properly if used in anger ?
>>
>
> FWIW, alpha and m68k are known boot with qemu (even though m68k
> generates a warning traceback with the mainline kernel).
At the very least I build every defconfig for every rc and release
kernel for m68k. I also run a ColdFire build through qemu (non-MMU)
and also run it and an MMU build on real hardware. So they are
always checked and by far mostly work - and when they don't I fix
it ASAP.
I am pretty sure Geert does similar for the traditional 68k targets.
NXP still sell ColdFire parts, so for the moment it is not dead
in terms of available silicon.
(*) I know linux-4.16-rc1 and rc2 issue a warning on boot of a
non-MMU m68k/coldfire build due to the addition of a warning by
Christoph in 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") but I haven't had a chance to track what the
exact problem is there.
Regards
Greg
On 02/22/2018 07:45 AM, 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.
>
> * 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.
Add blackfin to that list, there have been no responses from the
maintainers last time I posted patches to remove DSA header files, so we
had to go these through the networking tree. Have not see a Blackfin
pull request since forever, Aaron himself seems to agree this should be
removed:
http://lkml.iu.edu/hypermail/linux/kernel/1801.1/04345.html
--
Florian
On 02/23/2018 01:34 PM, Adam Borowski wrote:
> On Fri, Feb 23, 2018 at 02:32:08PM -0500, James Bottomley wrote:
>> On Fri, 2018-02-23 at 18:19 +0000, Al Viro wrote:
>> [...]
>>> IIRC, parisc/qemu stuff had been announced a while ago;
>>
>> I have, but it didn't work sufficiently for me to either boot a kernel
>> using system emulation or start an architecture container using user
>> emulation. I'll try again now that qemu has gone through several
>> revisions.
>
> Doesn't seem to work. Debian package (1:2.11+dfsg-1) ships hppa support but
> it doesn't even install binfmt; otherwise, -user is functional enough for a
> minimal executable (so arch-test reports it as working[1]), but not for
> anything libc:
>
> [/srv/chroots/hppa]# chroot . /usr/bin/qemu-hppa-static /bin/true
> qemu-hppa-static: /build/qemu-v8TF72/qemu-2.11+dfsg/target/hppa/translate.c:422: nullify_end: Assertion `status != DISAS_NORETURN && status != DISAS_IAQ_N_UPDATED' failed.
> Segmentation fault
>
> This looks bad enough that I didn't even look at qemu-system.
>
qemu-system-hppa support was added to qemu end of January. It seems to boot fine,
only I lost my ability to build a root file system :-( so it may take a bit
for me to create one.
Guenter
On 02/23/2018 11:32 AM, James Bottomley wrote:
> On Fri, 2018-02-23 at 18:19 +0000, Al Viro wrote:
> [...]
>> IIRC, parisc/qemu stuff had been announced a while ago;
>
> I have, but it didn't work sufficiently for me to either boot a kernel
> using system emulation or start an architecture container using user
> emulation. I'll try again now that qemu has gone through several
> revisions.
>
I can boot a parisc image to CLI using ToT qemu, ToT kernel built with
make ARCH=parisc CROSS_COMPILE=hppa-linux-" defconfig
make ARCH=parisc CROSS_COMPILE=hppa-linux-"
qemu command line:
qemu-system-hppa -nographic -monitor none -kernel vmlinux \
--append "console=/dev/ttyS0 root=/dev/sda" \
-drive file=rootfs.ext2,format=raw,if=scsi
I built the root file system using a modified buildroot based on 2018.02-rc2
with hppa support added.
Guenter
Am 22.02.2018 um 16:45 schrieb Arnd Bergmann:
> 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:
> [...]
> * 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.
It's mostly mentioned in the mailing list thread you linked to, but just
for completeness in this thread:
The OpenRISC GCC port is maintained and regularly updated to newer GCC
versions. It is not, however, upstreamed to the FSF due to a single
missing FSF copyright assignment from a developer who has written large
parts of the initial port. All code which has copyright assignments in
place (binutils, GDB, etc.) has been upstreamed lately.
For GCC, Stafford Horne is actively working on rewriting the parts which
we don't have the FSF copyright assignment for (and unless something
very surprising happens, won't get). [If anyone wants to help, there's
GSoC project for it as well:
https://fossi-foundation.org/gsoc18-ideas#openrisc-gcc-port]
So I'd be very sad if the openrisc port gets dropped from Linux upstream.
Philipp
On 02/23/2018 10:19 AM, Al Viro wrote:
> For m68k,
> IIRC, qemu is mostly for coldfire and friends with aranym
> working for m68k/MMU testing.
Laurent Vivier is in the process of fixing that upstream, it won't all make
qemu 2.12. He has a branch with full support for a Mac Quadra 800:
https://github.com/vivier/qemu-m68k/tree/q800-dev
r~
> FWIW, alpha and m68k are known boot with qemu (even though m68k
> generates a warning traceback with the mainline kernel).
M68K works - people actively use it. Crazy people true 8). Alpha I
believe one or two people boot. I just need to track down some discs for
my Alpha 8)
Alan
Hi!
On Sun 2018-02-25 20:28:06, Alan Cox wrote:
> > FWIW, alpha and m68k are known boot with qemu (even though m68k
> > generates a warning traceback with the mainline kernel).
>
> M68K works - people actively use it. Crazy people true 8). Alpha I
> believe one or two people boot. I just need to track down some discs for
> my Alpha 8)
I guess it would be useful to track who tested what kernel on what
hardware ... and I created a project for
that. Feel free to contribute: https://github.com/pavelmachek/missy --
I'd like to get some data from "big" iron...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sun, Feb 25, 2018 at 4:43 PM, Philipp Wagner
<[email protected]> wrote:
> Am 22.02.2018 um 16:45 schrieb Arnd Bergmann:
>> 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:
>> [...]
>> * 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.
>
> It's mostly mentioned in the mailing list thread you linked to, but just
> for completeness in this thread:
>
> The OpenRISC GCC port is maintained and regularly updated to newer GCC
> versions. It is not, however, upstreamed to the FSF due to a single
> missing FSF copyright assignment from a developer who has written large
> parts of the initial port. All code which has copyright assignments in
> place (binutils, GDB, etc.) has been upstreamed lately.
>
> For GCC, Stafford Horne is actively working on rewriting the parts which
> we don't have the FSF copyright assignment for (and unless something
> very surprising happens, won't get). [If anyone wants to help, there's
> GSoC project for it as well:
> https://fossi-foundation.org/gsoc18-ideas#openrisc-gcc-port]
>
> So I'd be very sad if the openrisc port gets dropped from Linux upstream.
Yes, definitely. What I was really trying to say here is I consider openrisc
an obvious exception to the 'no more ports without upstream gcc' rule
because of the above.
On a related note, has anyone successfully built an openrisc kernel with
llvm/clang? As we discussed for arch/hexagon/, that architecture is unlikely
to ever get an upstream gcc port, but like openrisc does have an upstream
llvm port and they actually use that.
I know that x86 and arm64 mostly work with llvm, arm32 works in some of
the more common configurations at least (not big-endian or older CPUs
though) and some others probably work as well. I have already build both
gcc-5.5 and gcc-7.3 for openrisc and uploaded those to
https://www.kernel.org/pub/tools/crosstool/files/bin/, but if llvm works as
well, that could be one more reason to try to build a working set of
clang based cross toolchains.
Arnd
On Sat, Feb 24, 2018 at 1:15 AM, Florian Fainelli <[email protected]> wrote:
> On 02/22/2018 07:45 AM, Arnd Bergmann wrote:
>
> Add blackfin to that list, there have been no responses from the
> maintainers last time I posted patches to remove DSA header files, so we
> had to go these through the networking tree. Have not see a Blackfin
> pull request since forever, Aaron himself seems to agree this should be
> removed:
>
> http://lkml.iu.edu/hypermail/linux/kernel/1801.1/04345.html
Peter Zijlstra also mentioned that one on IRC, I didn't have it on my radar
before. Like Tile, it has only recently been marked as Orphaned in MAINTAINERS,
so I'd be inclined to wait a little while to give possible users a
chance to step
up as new maintainers.
My plan for v4.17 is now:
- remove score, unicore and metag due to lack of toolchain
or interest from the maintainers.
- keep hexagon, and try to build an llvm/clang toolchain
- remove frv and m32r due to being abandoned for several years
- mark tile and blackfin for pending removal later this year unless
a new maintainer steps up
- mark mn10300 for pending removal unless it gets updated to
support chips that were made in the past 12 years and to build
properly.
Arnd
On 02/26/2018 09:00 AM, Arnd Bergmann wrote:
> On Sun, Feb 25, 2018 at 4:43 PM, Philipp Wagner
> <[email protected]> wrote:
>> Am 22.02.2018 um 16:45 schrieb Arnd Bergmann:
>>> 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:
>>> [...]
>>> * 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.
>>
>> It's mostly mentioned in the mailing list thread you linked to, but just
>> for completeness in this thread:
>>
>> The OpenRISC GCC port is maintained and regularly updated to newer GCC
>> versions. It is not, however, upstreamed to the FSF due to a single
>> missing FSF copyright assignment from a developer who has written large
>> parts of the initial port. All code which has copyright assignments in
>> place (binutils, GDB, etc.) has been upstreamed lately.
>>
>> For GCC, Stafford Horne is actively working on rewriting the parts which
>> we don't have the FSF copyright assignment for (and unless something
>> very surprising happens, won't get). [If anyone wants to help, there's
>> GSoC project for it as well:
>> https://fossi-foundation.org/gsoc18-ideas#openrisc-gcc-port]
>>
>> So I'd be very sad if the openrisc port gets dropped from Linux upstream.
>
> Yes, definitely. What I was really trying to say here is I consider openrisc
> an obvious exception to the 'no more ports without upstream gcc' rule
> because of the above.
>
> On a related note, has anyone successfully built an openrisc kernel with
> llvm/clang? As we discussed for arch/hexagon/, that architecture is unlikely
> to ever get an upstream gcc port, but like openrisc does have an upstream
> llvm port and they actually use that.
Actually the LLVM port of or1k isn't upstream either. CCing whitequark,
who might know more about the (non-)plans of getting the backend
upstream. I also don't know of anyone having tried to build the openrisc
kernel with LLVM, would certainly be an interesting thing to try.
> I know that x86 and arm64 mostly work with llvm, arm32 works in some of
> the more common configurations at least (not big-endian or older CPUs
> though) and some others probably work as well. I have already build both
> gcc-5.5 and gcc-7.3 for openrisc and uploaded those to
> https://www.kernel.org/pub/tools/crosstool/files/bin/, but if llvm works as
> well, that could be one more reason to try to build a working set of
> clang based cross toolchains.
Philipp
On 2018-02-26 12:10, Philipp Wagner wrote:
> Actually the LLVM port of or1k isn't upstream either. CCing
> whitequark, who might know more about the (non-)plans of getting the
> backend upstream. I also don't know of anyone having tried to build
> the openrisc kernel with LLVM, would certainly be an interesting thing
> to try.
I keep the OR1K backend up-to-date and generally in good shape (e.g.
I've got exception handling work and added all missing instructions
to the internal assembler) but upstreaming it is many weeks of work
that I personally cannot spare, and the LLVM community requests that
those who upstream backends maintain buildbots running hardware tests
indefinitely, which I personally cannot afford.
--
whitequark
Arnd Bergmann <[email protected]> writes:
> On Sat, Feb 24, 2018 at 1:15 AM, Florian Fainelli <[email protected]> wrote:
>> On 02/22/2018 07:45 AM, Arnd Bergmann wrote:
>>
>> Add blackfin to that list, there have been no responses from the
>> maintainers last time I posted patches to remove DSA header files, so we
>> had to go these through the networking tree. Have not see a Blackfin
>> pull request since forever, Aaron himself seems to agree this should be
>> removed:
>>
>> http://lkml.iu.edu/hypermail/linux/kernel/1801.1/04345.html
>
> Peter Zijlstra also mentioned that one on IRC, I didn't have it on my radar
> before. Like Tile, it has only recently been marked as Orphaned in MAINTAINERS,
> so I'd be inclined to wait a little while to give possible users a
> chance to step
> up as new maintainers.
>
> My plan for v4.17 is now:
>
> - remove score, unicore and metag due to lack of toolchain
> or interest from the maintainers.
> - keep hexagon, and try to build an llvm/clang toolchain
> - remove frv and m32r due to being abandoned for several years
> - mark tile and blackfin for pending removal later this year unless
> a new maintainer steps up
> - mark mn10300 for pending removal unless it gets updated to
> support chips that were made in the past 12 years and to build
> properly.
My frustration says please please please remove blackfin with sugar on
top. If you look at the new unified siginfo.h you will notice that
blackfin has the majority of conflicting si_code definitions.
Given that I have already dealt with the frustrating situations I can
wait a release or two. But even though I found a cross compiler for
blackfin there is a real cost to keeping it in the tree.
Eric
On Thu, Feb 22, 2018 at 11:43:10PM +0100, Arnd Bergmann wrote:
> - 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?
Just to follow up on this, the closest thing right now to compile the kernel
for Hexagon is the toolchain included with the Hexagon SDK. However, the
linker will fail because of something in the kernel build process that
I think produces empty sections, which that linker can't handle. A newer
linker can handle it, but that's not scheduled to be released until much later
this year.
That's actually the closest option currently. I tried the upstream source
but it seems to lack some specific patches to support kernel compilation,
so I will need to chase those down.
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
On Wed, Feb 28, 2018 at 3:06 AM, Richard Kuo <[email protected]> wrote:
> On Thu, Feb 22, 2018 at 11:43:10PM +0100, Arnd Bergmann wrote:
>> - 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?
>
> Just to follow up on this, the closest thing right now to compile the kernel
> for Hexagon is the toolchain included with the Hexagon SDK. However, the
> linker will fail because of something in the kernel build process that
> I think produces empty sections, which that linker can't handle. A newer
> linker can handle it, but that's not scheduled to be released until much later
> this year.
>
> That's actually the closest option currently. I tried the upstream source
> but it seems to lack some specific patches to support kernel compilation,
> so I will need to chase those down.
Thanks for trying it out. Can you point me to the sources? I tried downloading
a Hexagon SDK when I first looked at it, but only got a huge chunk of binary
java files and gave up before finding the llvm patches.
Arnd
On 02/23/2018 12:37 PM, Arnd Bergmann wrote:
> That makes more sense, yes. I'm still unsure about this one though. Chris in
> fact made the suggestion to remove the architecture from both glibc and kernel
> as with his departure from Mellanox there is nobody left from to maintain it.
>
> I suggested keeping it as 'Orphaned' for the time being, given that the port
> is still in a good shape, much better than many other ports.
>
> The known customers that sold TileGX based appliances (Cisco, Brocade,
> Checkpoint, Mikrotik, ...) tend to have long support cycles, and there have
> been attempts at getting Debian, OpenWRT and Centos distro support
> at least a few years ago.
Note that there is tilegx-*-linux-gnu and tilepro-*-linux-gnu. Only the
latter was removed from glibc.
Thanks,
Florian
On Wed, Feb 28, 2018 at 09:37:09AM +0100, Arnd Bergmann wrote:
> On Wed, Feb 28, 2018 at 3:06 AM, Richard Kuo <[email protected]> wrote:
> > On Thu, Feb 22, 2018 at 11:43:10PM +0100, Arnd Bergmann wrote:
> >> - 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?
> >
> > Just to follow up on this, the closest thing right now to compile the kernel
> > for Hexagon is the toolchain included with the Hexagon SDK. However, the
> > linker will fail because of something in the kernel build process that
> > I think produces empty sections, which that linker can't handle. A newer
> > linker can handle it, but that's not scheduled to be released until much later
> > this year.
> >
> > That's actually the closest option currently. I tried the upstream source
> > but it seems to lack some specific patches to support kernel compilation,
> > so I will need to chase those down.
>
> Thanks for trying it out. Can you point me to the sources? I tried downloading
> a Hexagon SDK when I first looked at it, but only got a huge chunk of binary
> java files and gave up before finding the llvm patches.
I don't think the SDK patches are available externally.
The good news is I think we're now one patch away from the upstream LLVM
compiling a functional kernel for Hexagon (a few fixes to LLVM/clang have
been committed already). It technically compiles but produces an abort (from
a null deref) which the linker doesn't like.
The linker itself unfortunately is going to be a different matter.
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
Since mprc.pku.edu.cn is blocked, I use this email account to send the email again.
> * 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.
>
Hi, Arnd.
I am really sorry to reply so late, since I seldom use this email account
in recent years. I will add my new email account to related bits.
Let me clarify the status of UniCore. It's a real cpu-core product,
integrated into PKUnity SoC, and sold in a large amount of embedded boxes,
such as cloud terminals and set top boxes. Surely, we still use the port
internally and keep doing developments in other projects. So, I really
appreciate having unicore32 port in the tree.
As to gnu toolchain of UniCore, I have already discussed it in my group,
and I'll do my best to propel it forward.
Thanks,
Guan Xuetao
On Fri, Mar 9, 2018 at 3:18 PM, Guan Xuetao <[email protected]> wrote:
> Since mprc.pku.edu.cn is blocked, I use this email account to send the email again.
>
>> * 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.
>>
> Hi, Arnd.
> I am really sorry to reply so late, since I seldom use this email account
> in recent years. I will add my new email account to related bits.
>
> Let me clarify the status of UniCore. It's a real cpu-core product,
> integrated into PKUnity SoC, and sold in a large amount of embedded boxes,
> such as cloud terminals and set top boxes. Surely, we still use the port
> internally and keep doing developments in other projects. So, I really
> appreciate having unicore32 port in the tree.
Ok, thanks for your reply, I'm dropping my removal patch then and will
try to document the current status better.
Can you send me a patch to the MAINTAINERS file update to the email
address? If you have no other patches at this point, I'll add that to my
patch series so at least you can be reached more easily.
> As to gnu toolchain of UniCore, I have already discussed it in my group,
> and I'll do my best to propel it forward.
Thanks, that would be very helpful!
Arnd
> * 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.
>
Hi, Arnd.
I am really sorry to reply so late, since I seldom use this email account
in recent years. I will add my new email account to related bits.
Let me clarify the status of UniCore. It's a real cpu-core product,
integrated into PKUnity SoC, and sold in a large amount of embedded boxes,
such as cloud terminals and set top boxes. Surely, we still use the port
internally and keep doing developments in other projects. So, I really
appreciate having unicore32 port in the tree.
As to gnu toolchain of UniCore, I have already discussed it in my group,
and I'll do my best to propel it forward.
Thanks,
Guan Xuetao