Deprecation/removal of nios2 target support

Deprecation/removal of nios2 target support

[Sandra Loosemore]

Tomorrow I plan to push patches to mark the nios2 target as obsolete in 
GCC 14.

Background: Intel has EOL'ed the Nios II processor IP and is now 
directing their FPGA customers to a RISC-V platform instead.

https://www.intel.com/content/www/us/en/content-details/781327/intel-is-discontinuing-ip-ordering-codes-listed-in-pdn2312-for-nios-ii-ip.html

The Nios II hardware on loan from Intel that we were using for testing 
at Mentor Graphics/Siemens was returned around the first of the year. 
For some time we had been using QEMU to test the nios2-elf target, but 
we never had a QEMU test harness set up that would boot the Linux 
kernel, and user-mode QEMU on this target is too buggy/unmaintained to 
use for primary testing.  So the current situation is that none of the 
listed maintainers for any of the GNU toolchain components have access 
to a fully working test configuration any more, we have all moved on to 
new jobs and different projects, Intel has also moved on to a different 
platform, and our former contacts on Intel's Nios II team have moved on 
as well.  It seems like it's time to pull the plug.

Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove 
support from all toolchain components after the release is made.  I'm 
not sure there is an established process for obsoleting/removing support 
in other components; besides binutils, GDB, and GLIBC, there's QEMU, 
newlib/libgloss, and the Linux kernel.  But, we need to get the ball 
rolling somewhere.

I did do some GCC testing on both ELF and Linux Nios II targets around 
the end of December and another round about a month ago, so I believe 
GCC 14 will pretty much be in working order.  Beyond that, though, I 
think it would be better to remove support promptly, rather than having 
it hang around in an unmaintained/untestable zombie state, getting ever 
more bit-rotten.

-Sandra

Re: Deprecation/removal of nios2 target support

[Thomas Huth]

On 18/04/2024 05.27, Sandra Loosemore wrote:
> Tomorrow I plan to push patches to mark the nios2 target as obsolete in GCC 14.
> 
> Background: Intel has EOL'ed the Nios II processor IP and is now directing 
> their FPGA customers to a RISC-V platform instead.
> 
> https://www.intel.com/content/www/us/en/content-details/781327/intel-is-discontinuing-ip-ordering-codes-listed-in-pdn2312-for-nios-ii-ip.html
> 
> The Nios II hardware on loan from Intel that we were using for testing at 
> Mentor Graphics/Siemens was returned around the first of the year. For some 
> time we had been using QEMU to test the nios2-elf target, but we never had a 
> QEMU test harness set up that would boot the Linux kernel, and user-mode 
> QEMU on this target is too buggy/unmaintained to use for primary testing.  
> So the current situation is that none of the listed maintainers for any of 
> the GNU toolchain components have access to a fully working test 
> configuration any more, we have all moved on to new jobs and different 
> projects, Intel has also moved on to a different platform, and our former 
> contacts on Intel's Nios II team have moved on as well.  It seems like it's 
> time to pull the plug.
> 
> Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove 
> support from all toolchain components after the release is made.  I'm not 
> sure there is an established process for obsoleting/removing support in 
> other components; besides binutils, GDB, and GLIBC, there's QEMU, 
> newlib/libgloss, and the Linux kernel.  But, we need to get the ball rolling 
> somewhere.

Thanks for the heads-up, Sandra! FWIW: QEMU already marked the nios2 target 
as deprecated, too, and plans to remove it in version 9.1 (in autumn this year).

  Thomas

Re: Deprecation/removal of nios2 target support

[Marek Vasut]

On 4/18/24 7:53 AM, Thomas Huth wrote:
> On 18/04/2024 05.27, Sandra Loosemore wrote:
>> Tomorrow I plan to push patches to mark the nios2 target as obsolete 
>> in GCC 14.
>>
>> Background: Intel has EOL'ed the Nios II processor IP and is now 
>> directing their FPGA customers to a RISC-V platform instead.
>>
>> https://www.intel.com/content/www/us/en/content-details/781327/intel-is-discontinuing-ip-ordering-codes-listed-in-pdn2312-for-nios-ii-ip.html
>>
>> The Nios II hardware on loan from Intel that we were using for testing 
>> at Mentor Graphics/Siemens was returned around the first of the year. 
>> For some time we had been using QEMU to test the nios2-elf target, but 
>> we never had a QEMU test harness set up that would boot the Linux 
>> kernel, and user-mode QEMU on this target is too buggy/unmaintained to 
>> use for primary testing. So the current situation is that none of the 
>> listed maintainers for any of the GNU toolchain components have access 
>> to a fully working test configuration any more, we have all moved on 
>> to new jobs and different projects, Intel has also moved on to a 
>> different platform, and our former contacts on Intel's Nios II team 
>> have moved on as well.  It seems like it's time to pull the plug.
>>
>> Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and 
>> remove support from all toolchain components after the release is 
>> made.  I'm not sure there is an established process for 
>> obsoleting/removing support in other components; besides binutils, 
>> GDB, and GLIBC, there's QEMU, newlib/libgloss, and the Linux kernel.  
>> But, we need to get the ball rolling somewhere.
> 
> Thanks for the heads-up, Sandra! FWIW: QEMU already marked the nios2 
> target as deprecated, too, and plans to remove it in version 9.1 (in 
> autumn this year).

Thank you and sorry for being inactive for so long around nios2.

Re: Deprecation/removal of nios2 target support

[Joseph Myers]

On Wed, 17 Apr 2024, Sandra Loosemore wrote:

> Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
> support from all toolchain components after the release is made.  I'm not sure
> there is an established process for obsoleting/removing support in other
> components; besides binutils, GDB, and GLIBC, there's QEMU, newlib/libgloss,
> and the Linux kernel.  But, we need to get the ball rolling somewhere.

CC:ing Arnd Bergmann regarding the obsolescence in the Linux kernel.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: Deprecation/removal of nios2 target support

[Joel Sherrill]

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

On Thu, Apr 18, 2024 at 10:46 AM Joseph Myers <josmyers@redhat.com> wrote:

> On Wed, 17 Apr 2024, Sandra Loosemore wrote:
>
> > Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
> > support from all toolchain components after the release is made.  I'm
> not sure
> > there is an established process for obsoleting/removing support in other
> > components; besides binutils, GDB, and GLIBC, there's QEMU,
> newlib/libgloss,
> > and the Linux kernel.  But, we need to get the ball rolling somewhere.
>
> CC:ing Arnd Bergmann regarding the obsolescence in the Linux kernel.
>

Just an FYI that the RTEMS Project plans to drop NIOS II support based
on what happens with the tooling.

--joel

>
> --
> Joseph S. Myers
> josmyers@redhat.com
>
>

Re: Deprecation/removal of nios2 target support

[Jeff Law]

On 4/18/24 9:57 AM, Joel Sherrill wrote:
> 
> 
> On Thu, Apr 18, 2024 at 10:46 AM Joseph Myers <josmyers@redhat.com 
> <mailto:josmyers@redhat.com>> wrote:
> 
>     On Wed, 17 Apr 2024, Sandra Loosemore wrote:
> 
>      > Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and
>     remove
>      > support from all toolchain components after the release is made. 
>     I'm not sure
>      > there is an established process for obsoleting/removing support
>     in other
>      > components; besides binutils, GDB, and GLIBC, there's QEMU,
>     newlib/libgloss,
>      > and the Linux kernel.  But, we need to get the ball rolling
>     somewhere.
> 
>     CC:ing Arnd Bergmann regarding the obsolescence in the Linux kernel.
> 
> 
> Just an FYI that the RTEMS Project plans to drop NIOS II support based
> on what happens with the tooling.
ACK.  Just one more note to the wider audience.  I looked at QEMU's user 
mode support for nios2 on/off over the last couple years.  It never 
seemed to work well enough be able to run the GCC testsuite reliably.

As a result, my tester builds nios2 and will run the testsuite, but all 
the execution tests are only built, they're not actually run.  It's been 
fairly stable, but its not doing in-depth testing.

jeff

Re: Deprecation/removal of nios2 target support

[Sandra Loosemore]

On 4/18/24 10:06, Jeff Law wrote:
> 
> ACK.  Just one more note to the wider audience.  I looked at QEMU's user 
> mode support for nios2 on/off over the last couple years.  It never 
> seemed to work well enough be able to run the GCC testsuite reliably.

I looked at the problems with the nios2 user-mode support in QEMU in 
some detail a few years ago.  It looked like the problem was that it had 
copied the target syscall data structures from GLIBC and wasn't 
accounting for 32-bit target/64-bit host differences -- this 
particularly affected signal handling.  I'm pretty sure we asked Intel 
if they wanted this fixed and they were not interested in pursuing that. 
  The end result is that user-mode QEMU is not very useful for GLIBC or 
GDB testing.

> As a result, my tester builds nios2 and will run the testsuite, but all 
> the execution tests are only built, they're not actually run.  It's been 
> fairly stable, but its not doing in-depth testing.

Yes, as I noted in my previous message, there is nothing seriously wrong 
with the nios2 GCC port at present; it just seems kind of pointless to 
invest time in continuing to maintain it as a hobby when the 
architecture is dead.  I think legacy customers generally would prefer 
to keep using the toolchains previously distributed by Altera/Intel or 
Mentor/Siemens instead of trying to build a new bleeding-edge toolchain 
from scratch, too.

-Sandra

Re: Deprecation/removal of nios2 target support

[Arnd Bergmann]

On Thu, Apr 18, 2024, at 17:44, Joseph Myers wrote:
> On Wed, 17 Apr 2024, Sandra Loosemore wrote:
>
>> Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
>> support from all toolchain components after the release is made.  I'm not sure
>> there is an established process for obsoleting/removing support in other
>> components; besides binutils, GDB, and GLIBC, there's QEMU, newlib/libgloss,
>> and the Linux kernel.  But, we need to get the ball rolling somewhere.
>
> CC:ing Arnd Bergmann regarding the obsolescence in the Linux kernel.

We have not yet marked nios2 as deprecated in the kernel, but that
is mostly because the implementation does not get in the way too
much and Dinh Nguyen is still around as a maintainer and merging
bugfixes.

Almost all nios2 kernel changes I see in the past decade have been
done blindly without testing on hardware, either for treewide
changes, or by code inspection. The only notable exceptions I could
find are from Andreas Oetken and Bernd Weiberg at Siemens and
from Marek Vasut (all added to Cc in case they have something to add).

We should probably remove nios2 from the kernel in the near future,
but even if we decide not to, I think deprecating it from gcc is the
right idea: If there are a few remaining users that still plan
to update their kernels, gcc-14 will still be able to build new
kernels for several years.

     Arnd

Re: Deprecation/removal of nios2 target support

[Marek Vasut]

On 4/18/24 8:41 PM, Arnd Bergmann wrote:
> On Thu, Apr 18, 2024, at 17:44, Joseph Myers wrote:
>> On Wed, 17 Apr 2024, Sandra Loosemore wrote:
>>
>>> Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
>>> support from all toolchain components after the release is made.  I'm not sure
>>> there is an established process for obsoleting/removing support in other
>>> components; besides binutils, GDB, and GLIBC, there's QEMU, newlib/libgloss,
>>> and the Linux kernel.  But, we need to get the ball rolling somewhere.
>>
>> CC:ing Arnd Bergmann regarding the obsolescence in the Linux kernel.
> 
> We have not yet marked nios2 as deprecated in the kernel, but that
> is mostly because the implementation does not get in the way too
> much and Dinh Nguyen is still around as a maintainer and merging
> bugfixes.
> 
> Almost all nios2 kernel changes I see in the past decade have been
> done blindly without testing on hardware, either for treewide
> changes, or by code inspection. The only notable exceptions I could
> find are from Andreas Oetken and Bernd Weiberg at Siemens and
> from Marek Vasut (all added to Cc in case they have something to add).

I might still have the 10M50 board, but it wasn't powered for a very 
long time.

Re: Deprecation/removal of nios2 target support

[Dinh Nguyen]

On 4/18/24 13:41, Arnd Bergmann wrote:
> On Thu, Apr 18, 2024, at 17:44, Joseph Myers wrote:
>> On Wed, 17 Apr 2024, Sandra Loosemore wrote:
>>
>>> Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
>>> support from all toolchain components after the release is made.  I'm not sure
>>> there is an established process for obsoleting/removing support in other
>>> components; besides binutils, GDB, and GLIBC, there's QEMU, newlib/libgloss,
>>> and the Linux kernel.  But, we need to get the ball rolling somewhere.
>>
>> CC:ing Arnd Bergmann regarding the obsolescence in the Linux kernel.
> 
> We have not yet marked nios2 as deprecated in the kernel, but that
> is mostly because the implementation does not get in the way too
> much and Dinh Nguyen is still around as a maintainer and merging
> bugfixes.
> 
> Almost all nios2 kernel changes I see in the past decade have been
> done blindly without testing on hardware, either for treewide
> changes, or by code inspection. The only notable exceptions I could
> find are from Andreas Oetken and Bernd Weiberg at Siemens and
> from Marek Vasut (all added to Cc in case they have something to add).
> 
> We should probably remove nios2 from the kernel in the near future,
> but even if we decide not to, I think deprecating it from gcc is the
> right idea: If there are a few remaining users that still plan
> to update their kernels, gcc-14 will still be able to build new
> kernels for several years.
> 

I'm planning to do this soon.

Dinh