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

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

[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

[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
josmy...@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 > 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

[Joel Sherrill]

On Thu, Apr 18, 2024 at 10:46 AM 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.
>

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

--joel

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

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

[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

[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