Re: Removing architectures without upstream gcc support
> * 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
> * 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
On Fri, Mar 9, 2018 at 3:18 PM, Guan Xuetaowrote: > 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
On Fri, Mar 9, 2018 at 3:18 PM, Guan Xuetao 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
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
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
On Wed, Feb 28, 2018 at 09:37:09AM +0100, Arnd Bergmann wrote: > On Wed, Feb 28, 2018 at 3:06 AM, Richard Kuowrote: > > 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
On Wed, Feb 28, 2018 at 09:37:09AM +0100, Arnd Bergmann wrote: > On Wed, Feb 28, 2018 at 3:06 AM, Richard Kuo 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
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
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
On Wed, Feb 28, 2018 at 3:06 AM, Richard Kuowrote: > 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
On Wed, Feb 28, 2018 at 3:06 AM, Richard Kuo 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
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
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 Bergmannwrites: > On Sat, Feb 24, 2018 at 1:15 AM, Florian Fainelli > 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
Arnd Bergmann writes: > On Sat, Feb 24, 2018 at 1:15 AM, Florian Fainelli > 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
On Sat, Feb 24, 2018 at 1:15 AM, Florian Fainelliwrote: > 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
On Sat, Feb 24, 2018 at 1:15 AM, Florian Fainelli 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
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 signature.asc Description: Digital signature
Re: Removing architectures without upstream gcc support
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 signature.asc Description: Digital signature
Re: Removing architectures without upstream gcc support
> 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
Re: Removing architectures without upstream gcc support
> 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
Re: Removing architectures without upstream gcc support
On 02/23/2018 11:32 AM, James Bottomley wrote: On Fri, 2018-02-23 at 18:19 +, 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
Re: Removing architectures without upstream gcc support
On 02/23/2018 11:32 AM, James Bottomley wrote: On Fri, 2018-02-23 at 18:19 +, 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
Re: Removing architectures without upstream gcc support
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 +, 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
Re: Removing architectures without upstream gcc support
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 +, 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
Re: Removing architectures without upstream gcc support
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
Re: Removing architectures without upstream gcc support
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
Re: Removing architectures without upstream gcc support
On 24/02/18 03:10, Guenter Roeck wrote: On Fri, Feb 23, 2018 at 03:43:16PM +, 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
Re: Removing architectures without upstream gcc support
On 24/02/18 03:10, Guenter Roeck wrote: On Fri, Feb 23, 2018 at 03:43:16PM +, 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
Re: Removing architectures without upstream gcc support
On Fri, Feb 23, 2018 at 02:32:08PM -0500, James Bottomley wrote: > On Fri, 2018-02-23 at 18:19 +, 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 ⠈⠳⣄
Re: Removing architectures without upstream gcc support
On Fri, Feb 23, 2018 at 02:32:08PM -0500, James Bottomley wrote: > On Fri, 2018-02-23 at 18:19 +, 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 ⠈⠳⣄
Re: Removing architectures without upstream gcc support
On Fri, 2018-02-23 at 18:19 +, 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 (linux-par...@vger.kernel.org) does regular build testing on a variety of 32 and 64 bit hardware. James
Re: Removing architectures without upstream gcc support
On Fri, 2018-02-23 at 18:19 +, 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 (linux-par...@vger.kernel.org) does regular build testing on a variety of 32 and 64 bit hardware. James
Re: Removing architectures without upstream gcc support
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.
Re: Removing architectures without upstream gcc support
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.
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 11:43:10PM +0100, Arnd Bergmann wrote: > On Thu, Feb 22, 2018 at 8:17 PM, Richard Kuowrote: > > 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
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 11:43:10PM +0100, Arnd Bergmann wrote: > On Thu, Feb 22, 2018 at 8:17 PM, Richard Kuo 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
Re: Removing architectures without upstream gcc support
On Fri, Feb 23, 2018 at 03:43:16PM +, 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
Re: Removing architectures without upstream gcc support
On Fri, Feb 23, 2018 at 03:43:16PM +, 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
Re: Removing architectures without upstream gcc support
> 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
Re: Removing architectures without upstream gcc support
> 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
Re: Removing architectures without upstream gcc support
On 02/23/2018 02:32 AM, Arnd Bergmann wrote: On Fri, Feb 23, 2018 at 12:48 AM, Guenter Roeckwrote: 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
Re: Removing architectures without upstream gcc support
On 02/23/2018 02:32 AM, Arnd Bergmann wrote: On Fri, Feb 23, 2018 at 12:48 AM, Guenter Roeck 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
Re: Removing architectures without upstream gcc support
On Fri, Feb 23, 2018 at 1:09 PM, Andy Shevchenkowrote: > On Fri, Feb 23, 2018 at 12:32 PM, Arnd Bergmann 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
Re: Removing architectures without upstream gcc support
On Fri, Feb 23, 2018 at 1:09 PM, Andy Shevchenko wrote: > On Fri, Feb 23, 2018 at 12:32 PM, Arnd Bergmann 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
Re: Removing architectures without upstream gcc support
On Fri, Feb 23, 2018 at 12:32 PM, Arnd Bergmannwrote: > 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
Re: Removing architectures without upstream gcc support
On Fri, Feb 23, 2018 at 12:32 PM, Arnd Bergmann 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
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 7:04 PM, Christoph Hellwigwrote: > On Thu, Feb 22, 2018 at 09:14:11AM -0800, Max Filippov wrote: >> On Thu, Feb 22, 2018 at 8:02 AM, Christoph Hellwig >> 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
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 7:04 PM, Christoph Hellwig 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 >> 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
Re: Removing architectures without upstream gcc support
On Fri, Feb 23, 2018 at 12:48 AM, Guenter Roeckwrote: > 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
Re: Removing architectures without upstream gcc support
On Fri, Feb 23, 2018 at 12:48 AM, Guenter Roeck 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
Re: Removing architectures without upstream gcc support
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
Re: Removing architectures without upstream gcc support
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
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 8:17 PM, Richard Kuowrote: > 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
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 8:17 PM, Richard Kuo 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
Re: Removing architectures without upstream gcc support
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
Re: Removing architectures without upstream gcc support
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
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 09:14:11AM -0800, Max Filippov wrote: > On Thu, Feb 22, 2018 at 8:02 AM, Christoph Hellwigwrote: > > 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.
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 09:14:11AM -0800, Max Filippov wrote: > On Thu, Feb 22, 2018 at 8:02 AM, Christoph Hellwig 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.
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 8:02 AM, Christoph Hellwigwrote: > 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
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 8:02 AM, Christoph Hellwig 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
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 5:28 PM, James Hoganwrote: > 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=151925667323732=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
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 5:28 PM, James Hogan 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=151925667323732=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
Re: Removing architectures without upstream gcc support
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=151925667323732=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 signature.asc Description: Digital signature
Re: Removing architectures without upstream gcc support
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=151925667323732=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 signature.asc Description: Digital signature
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 5:02 PM, Christoph Hellwigwrote: > 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
Re: Removing architectures without upstream gcc support
On Thu, Feb 22, 2018 at 5:02 PM, Christoph Hellwig 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
Re: Removing architectures without upstream gcc support
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: > 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
Re: Removing architectures without upstream gcc support
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 : > 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
Re: Removing architectures without upstream gcc support
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.
Re: Removing architectures without upstream gcc support
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.