Re: Removing architectures without upstream gcc support

Re: Removing architectures without upstream gcc support

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [OpenRISC] Removing architectures without upstream gcc support

[Arnd Bergmann]

On Sun, Feb 25, 2018 at 4:43 PM, Philipp Wagner
<lists@philipp-wagner.com> 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

Re: [OpenRISC] Removing architectures without upstream gcc support

[Philipp Wagner]

On 02/26/2018 09:00 AM, Arnd Bergmann wrote:
> On Sun, Feb 25, 2018 at 4:43 PM, Philipp Wagner
> <lists@philipp-wagner.com> 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

Re: [OpenRISC] Removing architectures without upstream gcc support

[whitequark]

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

Re: Removing architectures without upstream gcc support

[Arnd Bergmann]

On Sat, Feb 24, 2018 at 1:15 AM, Florian Fainelli <f.fainelli@gmail.com> 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

Re: Removing architectures without upstream gcc support

[Eric W. Biederman]

Arnd Bergmann <arnd@arndb.de> writes:

> On Sat, Feb 24, 2018 at 1:15 AM, Florian Fainelli <f.fainelli@gmail.com> 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

Re: Removing architectures without upstream gcc support

[Richard Kuo]

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

Re: Removing architectures without upstream gcc support

[Arnd Bergmann]

On Wed, Feb 28, 2018 at 3:06 AM, Richard Kuo <rkuo@codeaurora.org> 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

Re: Removing architectures without upstream gcc support

[Richard Kuo]

On Wed, Feb 28, 2018 at 09:37:09AM +0100, Arnd Bergmann wrote:
> On Wed, Feb 28, 2018 at 3:06 AM, Richard Kuo <rkuo@codeaurora.org> 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

Re: Removing architectures without upstream gcc support

[Florian Weimer]

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

Re: Removing architectures without upstream gcc support

[Xuetao Guan]

> * 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