Re: Removing architectures without upstream gcc support

Re: Removing architectures without upstream gcc support

[Guan Xuetao]

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

Re: Removing architectures without upstream gcc support

[Arnd Bergmann]

On Fri, Mar 9, 2018 at 3:18 PM, Guan Xuetao <gxt@pku.edu.cn> 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

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